Perl One Liner - absolute path to a directory

[edatz]

Having received some help from this forum, I thought it only fitting to give something back in return.

When I write a script or set of scripts, I always have a configuration file where things are set applicaton wide. For some years I had a section of code that returned the absolute path to the directory where the script resided. Recently someone I communicate with shared how he did it - and it's a lot shorter than my one. Definitely a handy item to have.

Perl One Liner - absolute path to a directory
$ENV{'SCRIPT_FILENAME'} =~ m|(.*)/(.*)$|; $ydir = $1;

Whichever script you put this in, will get the result. To use or show the result, do this:

print "$ydir\n";

or as part of another variable for something else inside that folder:

$anothervariable = "$ydir/somefolder/somefile";



Enjoy.

[Sixtease]

Ever heard of File::Basename module and its dirname function?

Nice sentiment though. :-)

[edatz]

Yes. You mean like this:

use File::Basename;
$dirname = dirname($ENV{'SCRIPT_FILENAME'});
print "$dirname";


Normally I don't use a module unless it's absolutely necessary. Mainly because I have some free scripts on my site and they have to be able to work on all servers, if possible. I've even seen some servers chop out some of the default ones that come with Perl - had one the chopped LWP, another one dumped DBM -- go figure. Sometimes my clients are not hosted on my server and I have the same problem.

[perl_diver]

File::Basename is a core module, has been for a long time. Neither LWP or DBM are core modules so its not a surprise if its not installed.

[edatz]

Hi perl_diver, yeah I saw that
File::Basename is a core module, has been for a long time. Neither LWP or DBM are core modules so its not a surprise if its not installed.
Yesterday 08:27 AM

I've never had need to use File::Basename.

DBM is (see http://perldoc.perl.org/index-modules-A.html - see alpha list for modules. LWP isn't on there - some older versons had it I think.

I did look up the DBI and it can handle some aspect of the FFDBs that I tend to use, though I have a feeling it would be over the top to call it for simple things like that. That's where DB_File would come in handy, but no server I've seen has kept it. Pity, I'd like to learn it.

[Sixtease]

Oh I use File::Basename all the time. Especially in this idiom to determine the directory where the script resides:
$PATH = &{ sub { dirname ((caller)[1]) } }

[edatz]

I will look into it There may be some other things it can do. If it is kept by all ISPs and Hosts, then fine. But some of them think that the less they have the safer they are - probably because they read some article written by a panic monger. Don't remember what it was, but one even banned the use of any scripts on their hosting server - cgi was banned. I had the client move to another service ('twas before I had my own hosting server).

You just gotta laugh at some of these jerks otherwise they'd drive us nuts.

[edatz]

Just read their docs, they say it's a bit quirky. Hmmmm.

dirname*
This function is provided for compatibility with the Unix shell command dirname(1) and has inherited some of its quirks. In spite of its name it does NOT always return the directory name as you might expect. To be safe, if you want the directory name of a path use fileparse() .

Only on VMS (where there is no ambiguity between the file and directory portions of a path) and AmigaOS (possibly due to an implementation quirk in this module) does dirname() work like fileparse($path) , returning just the $directories.

*(http://perldoc.perl.org/File/Basename.html)

No idea what VMS is so don't ask me...

[winracer]

this is good, I ried it and works. so how would I display the path and the name of the file / web page?.

[edatz]

Let's say you're using this to show the folder that you are working in on another script.

First you require your config script which has the ENV in. In another script that uses various items from the config script you need to do this:
require "myconfig.pl";

Then at whatever point you want in your HTML display you could have something like this;
print "You are currently in the $ydir directory\n";

As long as the script you are using requires the config file, where you place $ydir you can use or see it.

This also stand true within the config file itself. You can have several variables for different paths to various items with the $ydr as the root.
$ydir/users/data/users.db
or
$ydir/users/login.pl

This is only for parts of your code that require the full (absolute) path. You wouldn't need it if all you require is something like /cgi-bin/whatever (a relative path).

Best way is to play around with it in a script/scripts.

Hope that makes sense.

[Shorts]

Now the real question, would this one liner help me pick up a girl at a bar? I'll test it later and find out.

[winracer]

Let's say you're using this to show the folder that you are working in on another script.

First you require your config script which has the ENV in. In another script that uses various items from the config script you need to do this:
require "myconfig.pl";

Then at whatever point you want in your HTML display you could have something like this;
print "You are currently in the $ydir directory\n";

As long as the script you are using requires the config file, where you place $ydir you can use or see it.

This also stand true within the config file itself. You can have several variables for different paths to various items with the $ydr as the root.
$ydir/users/data/users.db
or
$ydir/users/login.pl

This is only for parts of your code that require the full (absolute) path. You wouldn't need it if all you require is something like /cgi-bin/whatever (a relative path).

Best way is to play around with it in a script/scripts.

Hope that makes sense.



thanks makes sence.
Don't really need it, but if I wanted to display the file I was working in, how would do do that.


like

if I am at /home/test/cig-bin/index.pl

then if I wanted, how could I have the script index.pl

print out

/home/test/cig-bin/index.pl

[edatz]

The actual file that you are in really only needs:


$ENV{'SCRIPT_FILENAME'};


If you had several forms, all being used within index.pl, then each form could use a variable set at the top of the script. For instance:

$thiscript ="$ENV{'SCRIPT_FILENAME'};";


Then each form wou simply have it's action like so:

<form action="$thiscript" method="">
formcontents
</form>

or to actually print the filename to the screen:
print "You are using $thiscript.";

[winracer]

The actual file that you are in really only needs:


$ENV{'SCRIPT_FILENAME'};


If you had several forms, all being used within index.pl, then each form could use a variable set at the top of the script. For instance:

$thiscript ="$ENV{'SCRIPT_FILENAME'};";


Then each form wou simply have it's action like so:

<form action="$thiscript" method="">
formcontents
</form>

or to actually print the filename to the screen:
print "You are using $thiscript.";




cool thanks it works!

[perl_diver]

Hi perl_diver, yeah I saw that


I've never had need to use File::Basename.

DBM is (see http://perldoc.perl.org/index-modules-A.html - see alpha list for modules. LWP isn't on there - some older versons had it I think.

I did look up the DBI and it can handle some aspect of the FFDBs that I tend to use, though I have a feeling it would be over the top to call it for simple things like that. That's where DB_File would come in handy, but no server I've seen has kept it. Pity, I'd like to learn it.

Ahh... my bad. :o

[Scriptage]

What's wrong with using $0 and chopping off the filename?

[Sixtease]

TMTOWTDI (http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it)

[Scriptage]

I am fully aware of the PERL mantras, however, it seems excessive to use modules or regular expressions to substitute a built in variable.

[Sixtease]

So how else would you chop off the filename? Using regexp or File::Basename seem as some of the simpler variants. Or would you prefer using substr and rindex? Or 1 while chop ne '/' perhaps?

[Scriptage]

To be honest I'd have gone with substr and rindex.

[Sixtease]

Yeah, I'd be tempted to as well. :-) But I'm so used to File::Basename that I stick to it.

[Scriptage]

As you say, each to their own. I tend to avoid regex for simple tasks if I can, using substr and rindex would be more transparent looking back at the code after a while.

[Sixtease]

Actually, I'd be tempted to use substr and rindex because of efficiency. I think the regexp would be more readable. But yeah, this is just personal taste. That's why I love Perl so much.

[Scriptage]

I don't doubt that it would be more efficient although the difference may be negligible.

But yeah, this is just personal taste. That's why I love Perl so much.


That's why we all love PERL so much :)

[Sixtease]

I'm sorry to be such an ass about it but it's Perl, not PERL. http://en.wikipedia.org/wiki/Perl#Name

[Scriptage]

I always took it as an acronym of Practical Extraction and Reporting Language; I was aware of the correct usage but I'm so used to the acronym form that it just slips out, I'll make a conscious effort to remember. :)

[svidgen]

I remember when I used to do everything in Perl ...

[Shorts]

Same here svidgen, those were the days...

Although, right now messing around with SDL_perl for some perl game development action in some of my extremely small amount of personal free time...

[svidgen]

There are days when I need a quick command-line script to parse a file when I think, "Hey, this would be perfect for Perl!" ... but then I remember that I don't have the appropriate database modules installed and I think, "Oh hey, these modules are built-in to PHP ..."

[Scriptage]

"Oh hey, these modules are built-in to PHP ..."

Yes but the downside to that is you have to program in PHP, just fire up PPM.

[svidgen]

Yes but the downside to that is you have to program in PHP ...
Haha! Silly programmer, Perl is for kids!

Seriously ... Perl is something people usually grow out of ...

lulz :D

[Scriptage]

I don't think any programmer worth his salt thinks that PHP is a better language than Perl.

[svidgen]

orly? is that why perl is on such heavy decline? it's just that great?

[Scriptage]

You are sorely mistaken dear boy: http://www.oreillynet.com/onlamp/blog/2007/08/perl_is_dead_long_live_perl.html

[svidgen]

An article from 2 years ago doesn't say a thing about what's happening now. Even for the time it was written, the article is purely speculatory based on a long-term trend (which are often misleading). And if you were to take a look at some historical data, you might find that the author was even more wrong at the time of his writing than he is now.

The big thing that's keeping Perl alive now is economic stress. You see a slight increase in Perl usage at the beginning of 2009, likely due to people cutting their budgets and being forced to stick with their existing Perl-driven systems ...

Even at that, Perl is currently back on a decline ...

... Maybe the problem is that you're looking at Perl usage in relation to itself, rather than in relation to "competing" languages?

[bluestartech]

perl one-liners are so cool!

[Shorts]

I think you guys are definitely comparing apples and oranges. Perl is a robust and complete language that can be used for pretty much anything (not just websites\crons) while PHP is more of a templating, website specific language.

But to say that perl is for kids and something that one grows out seems quite naive.

Two different languages, two different skill sets. PHP makes programming websites extremely easy and efficiently. Perl does whatever you need it to do.

Side note, coding like this is just fun:

print 'Bacon is tasty' unless $vegan;

[svidgen]

You're implying that PHP can't do "whatever you need it to?" ...

That's naive ...

PHP is every bit as capable as Perl, if not more-so. The two selling points of Perl are its syntactically integrated regular expressions and its community. The integrated regular expressions aren't that great when you consider how peculiar the code looks and the performance hit you take for using Perl to begin with. And the community is a negligible selling point when you consider the enormous communities that alternative languages have.

I'm not saying Perl isn't neat ... sure, it's neat. I still like it. But, it's also ugly, slow, and impractical.

EDIT:
Those integrated regular expressions are also pointless any time you're not parsing a complex input file (which most of the time).

[Shorts]

Again, think you're trying to compare apples and oranges. You're looking at Perl as though it is just a web development language. Which if that were the case think we'd both agree PHP is usually the easier\better one to go with.

However, out of curiosity just did a job search by me, one for Perl, one for PHP. For Perl I found 32 local results, all of them Software Development\Engineer related, zero for web development. For PHP there were 11 local results, all for Web Development.

And Perl is far from ugly, slow, and impractical. It all depends on the task on hand and who is developing in it. Same as it is for PHP.

[svidgen]

I use PHP for most command-line tools as well lately ... It executes faster and it's easier to read [by default].

Take a look at some non-local stats ... http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

[winracer]

now now why are you talking about PHP under the Perl forum.

Perl Rocks!

[Scriptage]

http://www.tiobe.com/index.php/content/paperinfo/tpci/tpci_definition.htm

I hardly find their methods of finding the most used language scientific. The point of the article I posted was in fact to show that the usage of Perl is not in decline, it is not a dying language.

A job search on monster.co.uk shows 103 Perl jobs (http://jobsearch.monster.co.uk/Search.aspx?q=perl&cy=uk&lid=193&re=130).

Perl isn't slower than PHP at all. Each language has its benefits and is faster than the other language in different areas: http://www.skitoy.com/p/performance-of-python-php-and-perl/160

PHP is every bit as capable as Perl, if not more-so.

PCRE uses the stack which results in a stack overflow when in deep recursion, this makes Perl's regular expressions far more powerful.

Up until version 5.3 PHP didn't even have namespaces or closures!

PHP doesn't support the functional (http://en.wikipedia.org/wiki/Functional_programming) and generic (http://en.wikipedia.org/wiki/Generic_programming) programming styles.

So no, PHP isn't every bit as capable as Perl and it definitely isn't more-so.

[svidgen]

You're talking about language flexibility--not capability. Flexibility is introduced into a language for folks who aren't bright enough to solve problems on their own ...

[svidgen]

PS ... I find it peculiar that the numbers on this site are completely out of sync with the numbers I've found on numerous other sites--more particularly my own benchmarks ...

Edit: In any case, Perl is a find choice for bulk text processing. But, I can't really see how that plays into most applications--particularly web apps, which is pretty much what this forum is about ... Bulk text processing is often nothing more than a failure to effectively use your database!

[Sixtease]

Shhh, what's the point of this battle? PHP and Perl can co-exist and will.

I love Perl and find writing in it very comfortable. It's used a lot in my field -- computational linguistics, and I can't imagine using PHP there. Both have its places, uses and favorers. Why does liking one imply rage against the other?

[svidgen]

Hey, I'm just trying to defend PHP's honor from the script-kiddies ...

... I've repeatedly said that Perl is neat. All I've been trying to say is that it's just on the decline because it's nowhere near the best option for web development anymore.

[Scriptage]

I don't know who you think you're calling a script kiddy sunshine.

You're talking about language flexibility--not capability. Flexibility is introduced into a language for folks who aren't bright enough to solve problems on their own ...

What a load of tosh that is; that's like saying PHP is for people that aren't bright enough to do Assembly.

My dislike of PHP comes mainly from the sloppiness of the language, how there isn't a naming convention to any of the built in functions. I've just started to look at PHP using the Zend Framework and it looks like it could be useful but even then that's nothing that Perl isn't capable of.

Perl is fantastic for text processing which means that you could template in XSLT and process with Perl, which personally I much prefer to the way you would template in PHP.

I still don't think that PHP is the finished article, when it gets to version 6 I might like it.

[Sixtease]

Perl is fantastic for text processing which means that you could template in XSLT and process with Perl, which personally I much prefer to the way you would template in PHP.
I think PHP is a great templating language! Way way more convenient than XSLT. For programming, I prefer Perl though. And with it, I prefer Template Toolkit, what a treasure!

when it gets to version 6 I might like it
This sentence is really marvelous in a Perl vs. PHP thread :-D

[svidgen]

Hehe ... Wasn't Perl supposed to undergo a major revision from 5.x to ??? (Parrot) about 2 years ago? Did that ever really happen? Or is Larry Wall still complaining about how ****ty his language turned out?

Just curious ...

[svidgen]

... I mean that in the most respectful way possible. I mean, I still think Perl is neat. And if I ever have a linguistics project to do, I'll probably use Perl ... I mean, at least for the initial data import ;)

[Sixtease]

Well, to be honest, I'm not very well informed about the progress on Perl6. I read somewhere it's in a usable state now but I never experimented with it. It has always disappointed me to see how outdated and seemingly dead the pages on Perl6 were that I found by a quick Google search whenever I did one. And I remember questions like "so what's up about Perl6?" popping up on PerlMonks every now and then.

But yes, Perl6 is very different from Perl5.

[svidgen]

... Yeah. Perl6 (Parrot, I think), was supposed to fix a lot of problems with Perl. And back when I was still using Perl several years ago, Perl6 was "just around the corner."

[Sixtease]

Parrot is the virtual machine Perl6 is supposed to run on. Perl6 on Parrot is called Rakudo, and I'm not sure about its phase of development but I think we'd know if it was finished. There's a Perl6 partial implementation on Perl5
use v6;
and there's an implementation on Haskell, called Pugs.

But don't take my word for it, it's just the bits that I remember and may be incorrect and outdated.

[Scriptage]

Hehe ... Wasn't Perl supposed to undergo a major revision from 5.x to ??? (Parrot) about 2 years ago? Did that ever really happen? Or is Larry Wall still complaining about how ****ty his language turned out?


Perl 6 isn't Larry Wall's language, he wanted it to be a community programmed language (much like PHP) which is why (to my knowledge) the progress is slow.


I think PHP is a great templating language! Way way more convenient than XSLT. For programming, I prefer Perl though. And with it, I prefer Template Toolkit, what a treasure!


The Zend Frameowrk way of doing things looks really interesting but as I said before I'm just beginning to look at it. I've never really looked at Template Toolkit.

[edatz]

Been busy trying to sort out a script and just came back to thread.

PHP. Well I tried a Hello World and got told off by the server about it being the wrong version of PHP.So I dumped the idea. A couple of months later the datacenter I hosted my server with got bought out and the new buyers upped the ante on PHP (without telling anyone) by a decimal point or something and several thousand sites went down because evidently it's not quite backward compatible with itself, like Perl is. That was confirmed at a conference three months later by a major teacher of PHP.

I think what we have with PHP is ASP for Unix and an easier language to learn than Perl. That coupled with media hype and more people looking for a starting place they can understand (well some of the time anyways).

Perl is difficult because you can do the same thing a hundred different ways and so you get input saying it has to be done like this or that. I find that puts off newcomers. Best, if you find something that works stick with it, develop your own code library and run with the thing. There are times you'll find something that is a lot better than what you are used to coding and that's where change comes. Then of course if you're like me trying figure out hashes and getting compeltely lost, you just simple scream loudly and go get a beer.

And all this from an artist who dabbles in Perl because he got frustrated by ugly code results :)

[perl_diver]

if you want a tool box, use PHP
if you want a machine shop, use perl

[svidgen]

Well I tried a Hello World and got told off by the server about it being the wrong version of PHP
Pretty sure this one works regardless of what version of PHP you're using:
Hello World.
Notice the lack of PHP "tags" ...

... it's not quite backward compatible with itself, like Perl is.
From what I recall reading in Programming Perl, 3rd ed., Perl isn't exactly backward-compatible all the time either. More particularly, Perl6 was never meant to be backward compatible (at all, really). If it happens to be backward compatible when it's finally finished, that's sort of a bonus ...

... of course, Perl6 was "just around the corner" about 6 years ago. I'm having doubts that a final release will ever come out.

Perl is difficult because you can do the same thing a hundred different ways ...
One of the misconceptions among Perl programmers is that the "more than one way to do it" concept is unique to Perl ... In fact, most of the examples you see in books about doing things in "more than one way" are common to just about every programming language.

Then of course if you're like me trying figure out hashes and getting compeltely lost ...
Wait ... you mean Perl's associative arrays? Or MD5/SHA1/* hashes?

If you're having trouble with Perl (the language) and not the concept of hashes in general (of the message-digest type), you should pick up O'Reilly's Programming Perl nth ed.. I have no idea what the latest edition is. But the 3rd edition was very helpful in a learning a great deal about Perl (much of which I've forgotten).

Perl is really great for what it's meant for (Practical Extraction and Reporting [Language]). Otherwise, it's probably the wrong tool for whatever job you're doing ...

[svidgen]

if you want a tool box, use PHP
if you want a machine shop, use perl
I had the exact same attitude 3 or 4 years ago. In fact, I thought only a moron would use something like PHP ...

... After doing some benchmarks and delving into it a bit more, PHP became the obvious choice for most web development tasks, regardless of how simple, easy, and non-1337 it seemed. And even at that, having spent some time in this forum (and the real world), it has become clear that both tools and 1337 h4x0rz can be found using PHP and/or Perl.

0f c04rs3 t3h 1337 h4x0rz u5u411y r341|1z3 h0w muc|-| b3++3r P|-|P 1z lulz!!!11

[perl_diver]

I have never thought only a moron would use PHP. There are lots of great PHP programs and lots of great PHP programmers. PHP is a good choice for webdev.

[perl_diver]

Perl is really great for what it's meant for (Practical Extraction and Reporting [Language]). Otherwise, it's probably the wrong tool for whatever job you're doing ...

Its silly broad brushing like your above comment that makes it impossible for me to agree with you in any sense of the word. Thats it for me.

[edatz]

From what I recall reading in Programming Perl, 3rd ed., Perl isn't exactly backward-compatible all the time either. More particularly, Perl6 was never meant to be backward compatible (at all, really). If it happens to be backward compatible when it's finally finished, that's sort of a bonus ...

I came in during Perl 4, didn't even know there was a 3. As for 6, I too doubt it will ever happen and if it does, there is too much out there in 4 & 5 that'd need redoing.

Perl is difficult because you .... I had meant to say Perl is difficult to learn.... sorry.

I have tried a number of PHP scripts and all of them had a not compatiable thing happen. I didn't write them, just wanted to see if they worked or not.

p_d mentions webdev, and maybe that's so. Perl has excellent database handling. The only thing I've seen (may be more) for PHP is MYSQL. Since I have no call to use RDB's I've not done anything in that direction.

Guess it's what you started with. For myself programming does not come naturally, where visual design and layout do. It's at the opposite end of the spectrum, so what p_d can do in an hour will take me months.

I even dream about it - like trying to move code to a different position on the wall so I can then make my browser change page so that I can see out the window and have a sandwich in the pouring characters coming from clouds of Photoshop filters running amuck. :eek:

[Scriptage]

From what I recall reading in Programming Perl, 3rd ed., Perl isn't exactly backward-compatible all the time either. More particularly, Perl6 was never meant to be backward compatible (at all, really). If it happens to be backward compatible when it's finally finished, that's sort of a bonus ...

Actually Perl 6 is backwards compatible with Perl 5:

Will I be able to convert my Perl 5 programs to Perl 6?
Yes. Larry Wall and others are already working on a Perl 5 to Perl 6 translator, which will be able to translate (most) Perl 5 source code to the equivalent Perl 6 syntax.

In addition, Perl 6 will provide a "Perl 5 compatibility mode", allowing the compiler to directly execute any code that it recognizes as being written in Perl 5.


However, to suggest that all of the versions of Perl were compatible with each other is misguided, I've had problems switching between 5.6 and 5.8 and I'm sure I've read about issues with 5.10.

One of the misconceptions among Perl programmers is that the "more than one way to do it" concept is unique to Perl ... In fact, most of the examples you see in books about doing things in "more than one way" are common to just about every programming language.

I couldn't agree more.

Perl is really great for what it's meant for (Practical Extraction and Reporting [Language]). Otherwise, it's probably the wrong tool for whatever job you're doing ...

That's just incorrect.

[edatz]

However, to suggest that all of the versions of Perl were compatible with each other is misguided, I've had problems switching between 5.6 and 5.8 and I'm sure I've read about issues with 5.10.
Though I've never had any problems on this, it may well be down the fact that I don't use any Perl 10 specific code. In which case I can see incompability. Maybe my code is so old that it doesn't matter :)

Actually Perl 6 is backwards compatible with Perl 5:
That's news to me. I had originally been to a conference some year back when it was found to have problems. So that's good that is.


Quote:
Perl is really great for what it's meant for (Practical Extraction and Reporting [Language]). Otherwise, it's probably the wrong tool for whatever job you're doing ...
That's just incorrect.

I agree. From what I've seen you can build some very complex applications that don't report. Friend works on BBC iPlayer and that uses Perl (plus a few other things)

I had the exact same attitude 3 or 4 years ago. In fact, I thought only a moron would use something like PHP ...
I'm still in pretty much that frame of mind - BUT, will take a more honest look at it. I'm retiring next year so probably won't get that much into it. Heck it's taken me several years just to get this far in Perl and even some simple things boil my brain.

[svidgen]

hehe ... people seem to be in great dislike of my last statement:
Perl is really great for what it's meant for (Practical Extraction and Reporting [Language]). Otherwise, it's probably the wrong tool for whatever job you're doing ...
Bear in mind, folks, I'm exaggerating a tiny bit here--but not much.

Remember, in terms of server side development (and system management scripting), I started with Perl. I reluctantly switched to PHP for web development and database interaction needs only after confirming through benchmarks that PHP didn't just make writing these apps quicker--it was a faster end-product too.

No one can really deny Perl's efficiency at parsing through giant chunks of text though ... I would still use Perl for a command line tool that needs to do some "serious" parsing. But mostly, I just use Perl now for nostalgia's sake ...