Mailing List Archive

[bug?] include mechanism
Hi list,

I started playing around with Apache::ASP the other day and encountered
a rather strange way of dealing with includes.

Let's say I have the following situation:

1 (folder)
+-- A (file)
+-- 2 (folder)
+-- B (file)
+-- C (file)

Let's also say we let:
A include B and
B include C

While we naturally use '#include file="2/B"' to include B from A, we
also naturally use '#include file="C"' to include C from B.
The problem is that this fails because it searches C in 1 rather than 2
due to the include simply not being aware of the fact that it was
basically called from within 2.
Calling B directly works, because ASP is then aware of being run in 2
and finds C accordingly.

While I personally consider this a bug, or a flaw at least, I would like
to hear the opinion of you guys.

regards,
Marko Friedemann
--
www.bmx-chemnitz.de -==- 20 Zoll in Chemnitz
mfr@bmx-chemnitz.de


---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
RE: [bug?] include mechanism [ In reply to ]
Maybe it should chdir into whatever directory each file it encounters,
before Parse()ing it.

Do you get the same problem if you use #include virtual="/2/C"?

-- John Drago



-----Original Message-----
From: Marko Friedemann [mailto:mfr@bmx-chemnitz.de]
Sent: Wednesday, July 07, 2004 2:14 AM
To: asp@perl.apache.org
Subject: [bug?] include mechanism

Hi list,

I started playing around with Apache::ASP the other day and encountered
a rather strange way of dealing with includes.

Let's say I have the following situation:

1 (folder)
+-- A (file)
+-- 2 (folder)
+-- B (file)
+-- C (file)

Let's also say we let:
A include B and
B include C

While we naturally use '#include file="2/B"' to include B from A, we
also naturally use '#include file="C"' to include C from B.
The problem is that this fails because it searches C in 1 rather than 2
due to the include simply not being aware of the fact that it was
basically called from within 2.
Calling B directly works, because ASP is then aware of being run in 2
and finds C accordingly.

While I personally consider this a bug, or a flaw at least, I would like
to hear the opinion of you guys.

regards,
Marko Friedemann
--
www.bmx-chemnitz.de -==- 20 Zoll in Chemnitz
mfr@bmx-chemnitz.de


---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [bug?] include mechanism [ In reply to ]
John Drago schrieb:

> Maybe it should chdir into whatever directory each file it encounters,
> before Parse()ing it.

That might be reasonable if it doesn't break anything else.

> Do you get the same problem if you use #include virtual="/2/C"?

Using #include virtual doesn't actually do anything. It just outputs the
comment as if it had missed the fact that it was meant to be considered.

Actually, while looking at it, I can't see the reference to "virtual="
in the code. I use 2.57 and line 724 in ASP.pm only has a regexp with
"file=" in it. Would that be parsed elsewhere and need a bit of config
in order for it to work?

regards,
Marko Friedemann
--
"Unsere Webseite arbeitet größtenteils mit CGI Scripts. Dies wird
meines Wissens von Mozilla nicht unterstützt. Verwenden Sie bitte
einen anderen Browser." -- Helmut S. - Technischer Support


---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
RE: [bug?] include mechanism [ In reply to ]
Take a look at the documentation here:
http://www.apache-asp.org/ssi.html

Quote:
"That is not all! SSI is full featured. One of the things missing above is
the
<!--#include virtual=filename.cgi-->

tag. This and many other SSI code extensions are available by filtering
Apache::ASP output through Apache::SSI via the Apache::Filter and the Filter
config options. For more information on how to wire Apache::ASP and
Apache::SSI together, please see the Filter config option documented above.
Also please see Apache::SSI for further information on the capabilities it
offers."


>> Maybe it should chdir into whatever directory each file it encounters,
>> before Parse()ing it.
>
>That might be reasonable if it doesn't break anything else.
>
>> Do you get the same problem if you use #include virtual="/2/C"?
>
>Using #include virtual doesn't actually do anything. It just outputs the
>comment as if it had missed the fact that it was meant to be considered.
>
>Actually, while looking at it, I can't see the reference to "virtual="
>in the code. I use 2.57 and line 724 in ASP.pm only has a regexp with
>"file=" in it. Would that be parsed elsewhere and need a bit of config
>in order for it to work?
>
>regards,
>Marko Friedemann
>--
>"Unsere Webseite arbeitet größtenteils mit CGI Scripts. Dies wird
> meines Wissens von Mozilla nicht unterstützt. Verwenden Sie bitte
> einen anderen Browser." -- Helmut S. - Technischer Support




---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [bug?] include mechanism [ In reply to ]
Quoting Marko Friedemann <mfr@bmx-chemnitz.de>:

> Hi list,
>
> I started playing around with Apache::ASP the other day and encountered
> a rather strange way of dealing with includes.
>
> Let's say I have the following situation:
>
> 1 (folder)
> +-- A (file)
> +-- 2 (folder)
> +-- B (file)
> +-- C (file)
>
> Let's also say we let:
> A include B and
> B include C
>
> While we naturally use '#include file="2/B"' to include B from A, we
> also naturally use '#include file="C"' to include C from B.
> The problem is that this fails because it searches C in 1 rather than 2
> due to the include simply not being aware of the fact that it was
> basically called from within 2.
> Calling B directly works, because ASP is then aware of being run in 2
> and finds C accordingly.
>
> While I personally consider this a bug, or a flaw at least, I would like
> to hear the opinion of you guys.
>

This is simply how it works, that the base directory includes are done from is
first the directory of the executing script, followed by the Global directory
and then any IncludesDir specified. This is really because the first directory
searched is '.' and there has already been a chdir to that base directory of
the executing script.

Regards,

Josh



> regards,
> Marko Friedemann
> --
> www.bmx-chemnitz.de -==- 20 Zoll in Chemnitz
> mfr@bmx-chemnitz.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
> For additional commands, e-mail: asp-help@perl.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [bug?] include mechanism [ In reply to ]
Joshua Chamas schrieb:

> Quoting Marko Friedemann <mfr@bmx-chemnitz.de>:
>
>>While we naturally use '#include file="2/B"' to include B from A, we
>>also naturally use '#include file="C"' to include C from B.
>>The problem is that this fails because it searches C in 1 rather than 2
>>due to the include simply not being aware of the fact that it was
>>basically called from within 2.
>>Calling B directly works, because ASP is then aware of being run in 2
>>and finds C accordingly.
>>
>>While I personally consider this a bug, or a flaw at least, I would like
>>to hear the opinion of you guys.
>
> This is simply how it works, that the base directory includes are done from is
> first the directory of the executing script, followed by the Global directory
> and then any IncludesDir specified. This is really because the first directory
> searched is '.' and there has already been a chdir to that base directory of
> the executing script.

Well, yes. This IS how it works. The question is wether it is actually
SUPPOSED to be that way and wether there is any security or whatever
other reason for it to be so.
I did say that I consider this a flaw, because it is not what you
usually want to do.

regards,
Marko
--
www.bmx-chemnitz.de -==- 20 Zoll in Chemnitz
mfr@bmx-chemnitz.de


---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [bug?] include mechanism [ In reply to ]
John Drago schrieb:

> Take a look at the documentation here:
> http://www.apache-asp.org/ssi.html

Doh, yeah, I actually read this page before. It wasn't, however,
immediately brought to my attention when I tried the virtual include.
I'll try to add SSI and see what it does.

regards,
Marko
--
www.bmx-chemnitz.de -==- 20 Zoll in Chemnitz
mfr@bmx-chemnitz.de


---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: [bug?] include mechanism [ In reply to ]
Quoting Marko Friedemann <mfr@bmx-chemnitz.de>:
> Well, yes. This IS how it works. The question is wether it is actually
> SUPPOSED to be that way and wether there is any security or whatever
> other reason for it to be so.
> I did say that I consider this a flaw, because it is not what you
> usually want to do.
>

Yes, it is supposed to work that way. Currently the context of includes does in
no way override the context of the base executing script. This is supposed to
be that way. I have never wanted to relatively change the include path to the
context of an included include, and I am not convinced that this is what one
usually wants to do, but I do understand the point you are making. The fact is
that when things have been working the way they have been for 5 years, there
needs to be a compelling reason to change things.

Regards,

Josh

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org