Is there a way I can include include files inside include files? (Say that five times fast!)
For example:
Inside index.html:
<!--#include virtual="/include-1.shtml"-->
Inside include1.shtml:
<!--#include virtual="/include-2.shtml"-->
So the tree looks like this: index.html <-- include_1.shtml <-- include_2.shtml
As is, this is not working on my Apache. The first include works fine, but the content for the nested include doesn't display.
As it is relevant, I am using the XBitHack on Apache 2, and I've double checked that both files are executable by the web user.
Help?
I know that this question is more than four years old, but for the benefit of people who, like me, find it thanks to StackOverflow's amazing search engine juice, here's how I made it work.
Under Apache2, you need to know this.
Relevant text:
This command inserts the text of the included file into the parsed file. SSI files may be nested, that is the included file may contain additional SSI statements (but in this case must have an .shtml suffix irrespective of the setting of XBitHack).
(Emphasis mine) For me, the solution lay in uncommenting two lines in the default httpd.conf:
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
… and changing the filename extension of the first-level included file to .shtml:
index.html
└─┬─ include1.shtml
└─── include2.html
Boom! Nested SSI works like a champion.
Make sure that Apache is actually trying to process the *.shtml files. Try putting
<!--#echo var="DATE_LOCAL" -->
in a *.shtml file and seeing if you get the expected results. Do you get the same result in a *.html file? If you don't see the dates in both, your configuration is off.
Related
Do you think its a bad habit - or a problem - to include the custom user machine path on the poedit translation paths?
"X-Poedit-SearchPath-0: /myProjectName/Backend/module/Core\n"
"X-Poedit-SearchPath-1: /Users/someUser/Documents/Projects/clipp/Backend/module/Core\n"
The first path is the global one, but as developers enter in the projects entries like the second path starts to appearing. This entries are versioned too and ends to populate the base with many alternatives.
Yes, it’s a bad thing to do. I consider it a design failure that Poedit even allows this and 1.8 is going to fix this part of its UI.
You are seeing yourself why it’s bad: it makes the PO file not portable to other machines. You should use a relative path (from the location of the PO file to …/module/Core instead.
See https://github.com/vslavik/poedit/wiki/PO-Extensions for description of the X-Poedit-* headers.
I have to work with a C/C++ build environment that drops intermediate files all over the place:
.i files containing the output of the C-preprocessor (roughly raw C)
.s files containing the input of the C-assembler
CEDET (I assume the semantic analyzer) eventually finds these files and attempts to index them. This results in jumping to .i files containing raw C for definitions and generally slowing down parsing and loading of the .semanticdb.
I never open these files in emacs, so they must be being loaded by the background analyser.
Is it possible to prevent the analyser from loading these files? I can't find any configuration options that define the file-types that are parsed by the background analyser.
If you never need C mode for these files, here's a quick fix:
(add-to-list 'auto-mode-alist '("\\.i\\'" . fundamental-mode))
(add-to-list 'auto-mode-alist '("\\.s\\'" . fundamental-mode))
The answer from abo-abo gave me the clues I needed. The grep implementation (used by EDE) of semantic-symref-perform-search uses auto-mode-alist to find matching files for a given semantic mode (based on the current buffer's mode - eg `c-mode) when trying to resolve symbols.
The final fix I used is to specifically eliminate the default entries in the auto-mode-alist using:
(delete '("\\.i\\'" . c-mode) auto-mode-alist)
(delete '("\\.ii\\'" . c++-mode) auto-mode-alist)
Adding fundamental-mode entries as suggested by abo-abo seems to work also, however I was concerned that since the c-mode entries were still in the list a change in implementation could result in them being reactivated.
I have a library and a console application that uses a library. The library has a folder with source and header files.
My project is in a child/inner directory but that library directory that I want to include is in a parent/upper directory.
My project directory:
H:\Gmail_04\gsasl-1.0\lib\libgsaslMain
Includes files are here:
H:\Gmail_04\gsasl-1.0\src
How can I use paths relative to the project directory, to include folders that are in a parent/upper directory?
Instead of using relative paths, you could also use the predefined macros of VS to achieve this.
$(ProjectDir) points to the directory of your .vcproj file, $(SolutionDir) is the directory of the .sln file.
You get a list of available macros when opening a project, go to
Properties → Configuration Properties → C/C++ → General
and hit the three dots:
In the upcoming dialog, hit Macros to see the macros that are predefined by the Studio (consult MSDN for their meaning):
You can use the Macros by typing $(MACRO_NAME) (note the $ and the round brackets).
If I get you right, you need ..\..\src
I have used a syntax like this before:
$(ProjectDir)..\headers
or
..\headers
As other have pointed out, the starting directory is the one your project file is in(vcproj or vcxproj), not where your main code is located.
By default, all paths you define will be relative. The question is: relative to what? There are several options:
Specifying a file or a path with nothing before it. For example: "mylib.lib". In that case, the file will be searched at the Output Directory.
If you add "..\", the path will be calculated from the actual path where the .sln file resides.
Please note that following a macro such as $(SolutionDir) there is no need to add a backward slash "\". Just use $(SolutionDir)mylibdir\mylib.lib.
In case you just can't get it to work, open the project file externally from Notepad and check it.
There are a couple of hints you need to know.
consider your app is running under c:\MyRepository\MyApp
a single dot on your path means the folder where your app runs. So if you like to reach some folder or file under MyApp folder (imagine c:\MyRepository\MyApp\Resources\someText.txt) you can do it like var bla = File.Exists(./Resources/someText.txt)
and you can go one level up with double dots (..) think about a folder under c:\MyRepository\SomeFolder\sometext.txt
for MyApp, it will be like
var bla = File.Exists(../SomeFolder/someText.txt)
and it is possible to go 2,3,4.. levels up like
../../SomeFolder (2 levels up)
../../../SomeFolder (3 levels up)
and path starting with no dots means the drive root. var bla = File.Exists(/SomeFolder/someText.txt) will look for the c:\SomeFolder\someText.txt in our scenario.
I'd like to include code from another source file. Does anyone know how to do that?
If your file is called foo.pl, you can include it using
:- [foo].
or, equivalently and a bit more explicit
:- consult(foo).
or, if you're worried it may be loaded several times in a larger app
:- ensure_loaded(foo).
or, if you're using full-blown modules
:- use_module(foo).
though the exact name of the last predicate differs between Prolog versions.
If you want to include the file literally - similar to #include, use
:- include('file.pl').
Most of the time it is preferable to structure your program using
modules, though.
I need to use a file for one of my tests written using Check. I initially hardcoded the path, which worked fine. However, this didn't work when the code is built outside of the source directory. I came up with the following solution which somewhat works. (I then prefix pathnames with TESTS_DIR)
# Set correct directory for test files
AS_IF([test "x$srcdir" = x.],
[TESTS_DIR=""],
[TESTS_DIR="$srcdir/tests/"])
AC_DEFINE_UNQUOTED([TESTS_DIR], ["$TESTS_DIR"], [directory for test files])
Unfortunately, this fails again for make distcheck. I could post specific path layouts and structures, but I'm wondering if there's an "easy" way to refer to files in the source directory in all these cases. Thanks!
UPDATE: I've tried to use absolute paths, but it seems $abs_top_srcdir isn't set when I tried to update the define in configure.ac. Any thoughts as to why that is would be appreciated.
I discovered that the problem was that $top_srcdir is not set at configure time. Instead, I added -DTESTS_DIR="\"$(top_srcdir)/tests/\"" to AM_CFLAGS in my tests Makefile.am and also added all directories containing test files to EXTRA_DIST.