|
Re: Out of a hole?
by ZZamboni (Curate) on Jul 06, 2000 at 06:21 UTC
|
The solution I can think of is to recursively open the "." and
".." directories, looking for the entries with the same inode
and building the path that way.
But that seems to be what the Cwd module does. And
Cwd is a standard module, so you don't need to install anything
extra (if that's what you want to avoid) and you don't have
to reinvent the wheel.
If you absolutely do not want to use modules (even standard
ones) for whatever reason, I would also suggest what nardo
said: look at Cwd.pm, extract the appropriate functionality
and put it in your code.
--ZZamboni
| [reply] |
|
|
<SCRIPT LANGUAGE="JavaScript">
</SCRIPT>
<NOSCRIPT>
</NOSCRIPT>
The solution I can think of is to recursively open the "." and ".."
directories, looking for the entries with the same inode and
building the path that way. But that seems to be what the Cwd
module does. And Cwd is a standard module, so you don't need to
install anything extra (if that's what you want to avoid) and you
don't have to reinvent the wheel. If you absolutely do not want to
use modules (even standard ones) for whatever reason, I would also
suggest what nardo said: look at Cwd.pm, extract the appropriate
functionality and put it in your code.
Thanks ZZamboni. That's sound advice. It is probably what i shall
do, while at the same time, for anybody losing sleep over this
(LOL) something came to my attention (that frayed, intermittently
failing attention ...) about the context of my perceived need to
find out about this: i probably won't have to do this after all.
The free Web serving at Tripod was the reason for this. I've wanted
to take advantage of the 50 free MB i have there and i needed to
make a script do some stuff .. kinda cool Perl stuff (when it works
-- it already does elsewhere but not on Tripod, so it's not as
bulletproof as I want it to be -- it will be posted for the
Brothers to look over). Anyway, on Tripod, the user cgi server
always sets the user cgi-bin dir as "root" and doesn't know of
anything else in the Universe above that. That simplifies things
meaning I know what `/'points to, now.
Anyway, good advice as I said, and i'll take a look at Cwd.pm when
i decide its time to tackle this.
| [reply] |
Re: Out of a hole?
by maverick (Curate) on Jul 06, 2000 at 07:17 UTC
|
well, if you're content with non-'pure perl' way of doing it
$pwd = `pwd`; # for unix
$pwd = `cd`; # I think, for that other OS I never use
chomp($pwd);
will give you the full path to the current working directory
/\/\averick | [reply]
[d/l] |
|
|
If you want to be a bit more platform independent then stick a test on $^O to determine what sort of machine your running on.
if($^O eq "MSWin32")
{
$pwd = `cd`;
}
else
{
$pwd = `pwd`;
}
Barn. | [reply]
[d/l] |
Re: Out of a hole?
by nardo (Friar) on Jul 06, 2000 at 05:14 UTC
|
If you are trying to figure out what directory you are in without using a module, you can edit Cwd.pm and include the relevant function(s) from Cwd.pm in your code. | [reply] |
RE: Out of a hole?
by ahunter (Monk) on Jul 06, 2000 at 14:48 UTC
|
require 'syscall.ph';
use strict;
use Carp;
sub cwd ()
{
my $buf = ' ' x 256;
$! = 0;
my $res = syscall(&SYS_getcwd, $buf, length($buf))
croak "getcwd: $!" if ($res == -1 && $! != 0);
$buf =~ /\0.*$//;
return $buf;
}
This obviously requires the syscall.ph header (and strict
and Carp, but you can get rid of them easily). If you
really don't want to use that either, you can find out
the value returned by SYS_getcwd. This goes beyond evil,
by the way, but under Linux (and probably nothing else),
this will work:
my $res = syscall(183, $s, length($s));
But it will almost certainly have radically different results on other operating systems!
Of course, if you are using Win32, it may not have getcwd,
but it may have an equivalent.
Andrew.
| [reply]
[d/l]
[select] |
Re: Out of a hole?
by Viking (Beadle) on Jul 06, 2000 at 17:54 UTC
|
| [reply]
[d/l] |
Re: Out of a hole?
by Maqs (Deacon) on Jul 06, 2000 at 21:01 UTC
|
May be i do not understand your needs, but would $ENV{'DOCUMENT_ROOT'} help you?
/Maqs. | [reply] |
|
|
No, you don't understand the need. Your solution revolves around a CGIish type solution. This question said nothing about that.
--
Casey
| [reply]
[d/l] |
|
|
Maqs wrote:
May be i do not understand your needs, but would
$ENV{'DOCUMENT_ROOT'} help you?
Mea Culpa, bigtime. Maqs is right (and nobody else is wrong but
me). I am working (as described in a little more detail in my reply
to ZZamboni's reply) on a CGI situation. Bingo. I should have
remembered to say so!
So, none of the other solutions posted here will apply to this
immediate situation. Because it's a strictly limited free server
with no shell access, I cannot run non-Perl system commands nor
will a lot of Perl things we take for granted work (like eval
..). Furthermore, installing user modules to this Tripod user space
is somewhat problematic too (I have done so other places, know all
about use lib `foo' and so on, thanks). Furthermore I have a
terribly limited subset of the "normal" ENV variables defined for
me there too. It's OK, I kind of like the challenges of working
with such limitations ... presents a challenge that warms my
hacker's heart ;).
I ramble. Anyway I am not going to be able to reply to everyone who
posted a reply, please let me get away with a blanket "thanks" to
all.
Intrepid
| [reply] |