[27317] in Perl-Users-Digest
Perl-Users Digest, Issue: 9046 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Mar 12 18:06:53 2006
Date: Sun, 12 Mar 2006 15:05:05 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 12 Mar 2006 Volume: 10 Number: 9046
Today's topics:
Re: Paths help <tadmc@augustmail.com>
Re: Paths help <1700-820@onlinehome.de>
Re: Paths help hope@hope.com
Re: Paths help <no@email.com>
Re: Paths help hope@hope.com
Re: Paths help <tadmc@augustmail.com>
Re: Source Code Analyzing <thepoet_nospam@arcor.de>
Re: Source Code Analyzing <rvtol+news@isolution.nl>
Re: Source Code Analyzing <uri@stemsystems.com>
Re: Source Code Analyzing <daniel@QMiC.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 12 Mar 2006 09:33:48 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Paths help
Message-Id: <slrne18fqs.3l7.tadmc@magna.augustmail.com>
hope@hope.com <hope@hope.com> wrote:
> $folder="users\\uxxx\\perdata\\users";
> @userfiles=`dir $folder`;
> $folder="users/uxxx/perdata/users";
>
> Now my users are in
>
> C:\apache\Apache2\htdocs\web1\test\users
So then, change the value in $folder:
$folder = "C:\\apache\\Apache2\\htdocs\\web1\\test\\users"; # absolute path
Or, much better, use native Perl instead of shelling-out to
system-specific utilities. That would allow you to completely
eliminate backslashes and backslashing of backslashes:
# untested
my $folder = 'C:/apache/Apache2/htdocs/web1/test/users';
opendir USERS, $folder or die "could not open '$folder' $!";
my @userfiles = readdir USERS;
closedir USERS;
or:
# untested
my $folder = 'C:/apache/Apache2/htdocs/web1/test/users';
my @userfiles = glob "$folder/*"; # may fail with really old perls
> I have put in
>
> $folder="..\\..\\htdocs\\web1\\test\\users";
A path relative to your current working directory.
> I have put in
>
> $folder="htdocs\\web1\\test\\users";
Another path relative to your current working directory.
> I have put in
> $folder="\web1\\test\\users";
An absolute path, to a directory that probably does not exist
on your filesystem.
> PLEASE can some one help on this paths thing for me
>
> 1) why the two \\ in the first one
Because you used double quotes. Backslashes are "meta" in
double-quoted strings, so you need to backslash the backslash
if you instead want a single _literal_ backslash character
to be in the resulting string.
You would not need to double them up if you choose to use
single quotes instead:
$folder = 'users\uxxx\perdata\users';
> 2) Then why the/ on the second one.
I dunno.
The value of the $folder variable is never used again in the code
that you have shown us, so as far as we know, it is for no
reason at all.
_You_ are the one who put that code in there, _you_ tell us why.
What does your code do with $folder after the change?
> Can you please explain in simple terms how you go from one folder up from where you are or
> down from where you are.
Before you do that, you must determine exactly "where you are", in
other words, you must determine what your current working directory
is if you hope to use relative paths.
If you use an absolute path instead of a relative path, then your
current working directory will not matter at all.
> So if I had
>
> cgi-bin\test and in the test folder I had test.cgi
Where your program is located is NOT necessarily the same as
your current working directory.
So, we do not need to know where your program is, because it
is irrelevant.
We _do_ need to know what your current working directory is (if
relative paths are to be used).
> In the test.cgi I wanted to goto
> htdocs\test\test
^^^^
^^^^
Where did that 2nd test/ directory ("folder") come from?
> How would I put the path.
The easiest way would be to use an absolute path instead of
a relative one, but we do not know what that path is on your
system, because we do not know how your system is configured.
It might kinda sorta be something approximately like:
$folder = 'C:\apache\Apache2\htdocs\test'; # absolute path
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sun, 12 Mar 2006 15:54:13 +0100
From: Josef =?ISO-8859-2?Q?M=F6llers?= <1700-820@onlinehome.de>
Subject: Re: Paths help
Message-Id: <dv1cmp$vap$1@online.de>
hope@hope.com wrote:
> I trying to sort out how to put in pathes
>
> I have apache setup like
> C:\apache\Apache2\
> cgi-bin
> Htdocs
>
> Now in my cgi-bin folder I have a folder called test
> In this folder I have a script called test.cgi
>
> It has in it
> ## GET USERS
>
> $folder="users\\uxxx\\perdata\\users";
> @userfiles=`dir $folder`;
> $folder="users/uxxx/perdata/users";
>
> Now my users are in
>
> C:\apache\Apache2\htdocs\web1\test\users
>
> I have put in
>
> $folder="..\\..\\htdocs\\web1\\test\\users";
> @userfiles=`dir $folder`;
> $folder="../../htdocs/web1/test/users";
>
> That does not work
>
> I have put in
>
> $folder="htdocs\\web1\\test\\users";
> @userfiles=`dir $folder`;
> $folder="htdocs/web1/test/users";
>
> That does not work
>
> I have put in
> $folder="\web1\\test\\users";
> @userfiles=`dir $folder`;
> $folder="/htdocs/web1/test/users";
>
>
> That does not work
It appears that you have just randomly changed things in the hope that, at
one point, the script would behave as you expect it to behave.
It reminds one of the idea that, given enough monkeys with typewriters, one
day Shakespear's Hamlet will be typed by one of them.
The drawbacks of this approach are
1. You have no idea why it suddenly works
2. You have no idea what the side effects of your action are.
You may have built in a large security hole or a bug that will bite you in
the furture.
> PLEASE can some one help on this paths thing for me
>
> 1) why the two \\ in the first one
The backslash (\) is a special character in Perl's double-quoted strings: it
sometimes gives special meaning to the letter which follows it: it will
turn an n into a newline, an r into a carriage return, a closing " into a
quote within a string etc. Here it will turn the special character \ into a
simple character \.
> 2) Then why the/ on the second one.
The / is not a special character in Perl's strings (Note that some OSes do
not mind if you wrote a//path//to//a//file).
The difference between these two strings will become obvious, if you use
them with external programs:
The first strings will turn into 'a\path\to\a\file' (note the single quote!)
while the second ones will turn into 'a/path/to/a/file'. If you pass either
of these strings to a
> @userfiles=`dir $folder`;
the "dir" command will, in one case, find a backslashed path and in the
other case a forward-slashed path. The first one is OK, the second one
isn't.
Beware that if you passed a pathname to a Perl-builtin, then perl will
automagically convert forward slashes to a backslashes.
> Can you please explain in simple terms how you go from one folder up from
> where you are or down from where you are.
See Brian's post.
--
josef punkt moellers bei gmx punkt de
------------------------------
Date: Sun, 12 Mar 2006 16:40:22 GMT
From: hope@hope.com
Subject: Re: Paths help
Message-Id: <50k8121jia19ujf775vgelb17bapbu9kju@4ax.com>
On Sun, 12 Mar 2006 13:27:55 +0000, Brian Wakem <no@email.com> wrote:
>hope@hope.com wrote:
>
>> Now my users are in
>>
>> C:\apache\Apache2\htdocs\web1\test\users
>>
>> I have put in
>>
>> $folder="..\\..\\htdocs\\web1\\test\\users";
>> @userfiles=`dir $folder`;
>> $folder="../../htdocs/web1/test/users";
>
>
>../../ moves you up the dir tree two levels, which puts us in
>C:/apache/Apache2/htdocs/web1, so ../../htdocs/web1/test/users is the same
>as C:/apache/Apache2/htdocs/web1/htdocs/web1/test/users
>
>
>> PLEASE can some one help on this paths thing for me
>>
>> 1) why the two \\ in the first one
>
>
>No idea, you've done that, how can I explain your actions?
>
>
>> 2) Then why the/ on the second one.
>
>
>That's how it should be.
>
>
>
>> Can you please explain in simple terms how you go from one folder up from
>> where you are or down from where you are.
>
>
>../ moves up the dir tree.
>
>./dirname moves down.
>
>
>> So if I had
>>
>> cgi-bin\test and in the test folder I had test.cgi
>> In the test.cgi I wanted to goto
>> htdocs\test\test
>
>
>Easier to use an absolute path, but it would be ../../htdocs/test/test
Hi Brian
Thank you so much for a SIMPLY answer.
I think I have it now
So I have my setup like
Apache
Apach2
Cgi-bin/test
htdocs/test
So if I was in cgi-bin/test and I wanted to goto htdocs/test I would put in
../../htdocs/test.
../ = upto cgi-bin
../../ = upto cgi-bin then to htdocs
so in fact my statment would say
go upto cgi-bin then to htdocs then down to htdocs the inside htdocs got test
Have I got that right?
Many thanks
------------------------------
Date: Sun, 12 Mar 2006 17:02:04 +0000
From: Brian Wakem <no@email.com>
Subject: Re: Paths help
Message-Id: <47j2gdFfvofqU1@individual.net>
hope@hope.com wrote:
> I think I have it now
>
> So I have my setup like
>
>
> Apache
> Apach2
> Cgi-bin/test
> htdocs/test
>
>
> So if I was in cgi-bin/test and I wanted to goto htdocs/test I would put
> in
>
> ../../htdocs/test.
>
>
> ../ = upto cgi-bin
Right.
> ../../ = upto cgi-bin then to htdocs
Wrong. Upto cgi-bin, then upto apache2
> so in fact my statment would say
>
> go upto cgi-bin then to htdocs then down to htdocs the inside htdocs got
> test
>
> Have I got that right?
No. Upto cgi-bin, then up to apache2, then down to htdocs, then down to
test.
--
Brian Wakem
Email: http://homepage.ntlworld.com/b.wakem/myemail.png
------------------------------
Date: Sun, 12 Mar 2006 19:38:50 GMT
From: hope@hope.com
Subject: Re: Paths help
Message-Id: <t1u8129ksrm9q7p8lrhpg4o7e8egas8fql@4ax.com>
On Sun, 12 Mar 2006 17:02:04 +0000, Brian Wakem <no@email.com> wrote:
>hope@hope.com wrote:
>
>> I think I have it now
>>
>> So I have my setup like
>>
>>
>> Apache
>> Apach2
>> Cgi-bin/test
>> htdocs/test
>>
>>
>> So if I was in cgi-bin/test and I wanted to goto htdocs/test I would put
>> in
>>
>> ../../htdocs/test.
>>
>>
>> ../ = upto cgi-bin
>
>
>Right.
>
>
>> ../../ = upto cgi-bin then to htdocs
>
>
>Wrong. Upto cgi-bin, then upto apache2
>
>
>> so in fact my statment would say
>>
>> go upto cgi-bin then to htdocs then down to htdocs the inside htdocs got
>> test
>>
>> Have I got that right?
>
>
>No. Upto cgi-bin, then up to apache2, then down to htdocs, then down to
>test.
Hi Brian
Many thanks for your help.
I have got it all now Ha Ha
Very simple when you know how.
------------------------------
Date: Sun, 12 Mar 2006 15:41:43 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Paths help
Message-Id: <slrne195cn.4e7.tadmc@magna.augustmail.com>
Josef Möllers <1700-820@onlinehome.de> wrote:
> hope@hope.com wrote:
>> $folder="/htdocs/web1/test/users";
>> 2) Then why the/ on the second one.
>
> The / is not a special character in Perl's strings
Right.
> (Note that some OSes do
> not mind if you wrote a//path//to//a//file).
And those OSes include the OP's platform (Windows) if I am not mistaken.
Backslashes are not a problem in Windows filesystems.
Backslashes are a problem in some "command interpreters" (shells).
(when you are using a GUI, there is no shell, so try using forward
slashes in a GUI file requester. I'll betcha it works just fine.
)
> while the second ones will turn into 'a/path/to/a/file'. If you pass either
> of these strings to a
>
>> @userfiles=`dir $folder`;
>
> the "dir" command will, in one case, find a backslashed path and in the
> other case a forward-slashed path. The first one is OK, the second one
> isn't.
Right, because backticks invoke a "command interpreter", and the
forward slashes confuse it (because it uses forward slashes for
something else).
> Beware that if you passed a pathname to a Perl-builtin, then perl will
> automagically convert forward slashes to a backslashes.
I don't think that is true.
Is there a place in the std docs that supports that?
I think if you passed a forward-slashed pathname to a Perl-builtin,
it works unchanged (because there is no command interpreter involved,
perl goes to the system libraries directly).
But I could well be wrong, having never programmed on Windows...
Am I wrong?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sun, 12 Mar 2006 17:13:10 +0100
From: Christian Winter <thepoet_nospam@arcor.de>
Subject: Re: Source Code Analyzing
Message-Id: <44144897$0$12911$9b4e6d93@newsread4.arcor-online.net>
Daniel Zinn wrote:
> Hey,
>
> I am not sure if I tried hard enough[1], but perhaps you can guide me, where
> to go on with reading, or even propose some code sniplets. Ok, here is the
> problem:
>
> I want to analyze a Perl program. I want to transform every "line/statement"
> of a given Perl script into a more abstract syntax which only deals with
> function and variable definitions and calls/usage.
>
> So, basicly my new "simplified" grammar looks like:
> data Prog = Var VarName -- a variable is used
> | Call FuncName -- a function is called
> | Sub FuncName Prog -- FuncName is new function; body=Prog
> | SubClos Prog -- an anom. function is created as closure
> | Dyn VarName -- a "local" variable declaration
> | Lex VarName -- a "my" variable declaration
> | Block Prog -- just a { ... } block
> | Skip -- something else
> (sorry for this Haskell code over here, please don't feel offended ;))
>
> So, since Perl is 'kind of' not easy to parse directly, I thought of using
> the B module.
Hi,
I don't know about a B:: approach, but if you happen to get your
hands on the April issue of the German "Linux Magazin" you might
find the article "Uebersetzungskuenstler" of help. It gives an
example on how to use Parse::Lex (it focusses on basic math
calculations, but it might be a good starting point) to parse a
custom grammar.
-Chris
------------------------------
Date: Sun, 12 Mar 2006 17:38:50 +0100
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: Source Code Analyzing
Message-Id: <dv1mev.1go.1@news.isolution.nl>
Daniel Zinn schreef:
> I want to analyze a Perl program. I want to transform every
> "line/statement" of a given Perl script into a more abstract syntax
> which only deals with function and variable definitions and
> calls/usage.
http://ali.as/ "Parsing Perl"
CPAN: PPI
--
Affijn, Ruud
"Gewoon is een tijger."
echo 78B3649D3C106E1056C42A10F |perl -pe 'tr/0-9A-F/rectal JunkshoP,/'
------------------------------
Date: Sun, 12 Mar 2006 13:42:32 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Source Code Analyzing
Message-Id: <x71wx7ec87.fsf@mail.sysarch.com>
>>>>> "R" == Ruud <rvtol+news@isolution.nl> writes:
R> Daniel Zinn schreef:
>> I want to analyze a Perl program. I want to transform every
>> "line/statement" of a given Perl script into a more abstract syntax
>> which only deals with function and variable definitions and
>> calls/usage.
R> http://ali.as/ "Parsing Perl"
R> CPAN: PPI
i was going to mention that module too. it will do what the OP wanted
but it has one caveat, it isn't a true deep parser of perl5. it does a
high quality lexical analysis (which is what the OP wanted). it won't
load modules and pragmas which can change the syntax of following code
(which perl5 handles, of course).
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Sun, 12 Mar 2006 15:02:11 -0800
From: Daniel Zinn <daniel@QMiC.de>
Subject: Re: Source Code Analyzing
Message-Id: <dv29kh$cvl$1@newsserver.rz.tu-ilmenau.de>
Uri Guttman wrote:
>
> i was going to mention that module too. it will do what the OP wanted
> but it has one caveat, it isn't a true deep parser of perl5. it does a
> high quality lexical analysis (which is what the OP wanted). it won't
> load modules and pragmas which can change the syntax of following code
> (which perl5 handles, of course).
First, thank you for that hint. I didn't know about PPI.
After reading about it (and trying it out) I really think, I want to use the
B framework[1].
B::Xref is almost what I need. Unfortunately, it does not tell me where
{ and } are in the code[2]. I am pretty sure that B knows about these
blocks, but they are just not noticed by the B::Xref module.
So, can anyone help me to understand how B::Xref (or B in general) works,
and even better could anyone give me a hint how to "print out" { and } --
starting and ending block delimiters?
Thank you,
Daniel
[1]
The main reason is that I want to change the Perl code slightly without
breaking it's meaning. The B framework is geared to transform Perl code
without changing the meaning (well, it tries the best). The PPI interface,
on the otherside is to high-level. For example in 'print "x = $x\n";' PPI
tells me that there is a double quoted string - and I have to parse the
string on myself if I want to figure out the x is used inside this string.
Also the B modules do a much better job in understanding the Perl code
(they, for example load pm files...)
[2]
this is important, because:
8<---------------------------
sub foo {
{
local $x = 5; # line 5
print $x,"\n"; # line 6
}
print "$x\n"; # line 8
}
my $bla;
local $x = 6;
foo();
8<---------------------------
is transformed into something like:
localNesting.pl foo 5 main $ x intro
localNesting.pl foo 6 main $ x used
localNesting.pl foo 8 main $ x used
unfortunately, $x in line 8 is not the $x which is introduced in line 5,
because of the curly braces.
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 9046
***************************************
