Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Re: Perl on a Mac - again

Reply
Thread Tools

Re: Perl on a Mac - again

 
 
Martijn Lievaart
Guest
Posts: n/a
 
      04-22-2012
On Sun, 22 Apr 2012 10:03:26 +0200, Hacker wrote:

> On 2012-04-22 06:11:26 +0000, Hacker said:
>
>> I have a little Perl program here:
>>
>> #!usr//bin/perl print "Hello World";
>>
>> it is called 'test'.
>>
>> When I write 'perl test' on the command line it works fine and comes
>> out with 'Hello World' just as it should, but when I write 'test' on
>> the command line there is no output.
>>
>> What is wrong.

>
> Considering I had written #!usr//bin/perl right as #!/usr/bin/perl but
> that is corrected now and there is still no output when you 'execute'
> the file.
>
> Any real dogs out there, or am I a moron.


You are executing the test binary. Do a which test to see what you are
executing,or use ./test to start your own script.

M4
 
Reply With Quote
 
 
 
 
Mart van de Wege
Guest
Posts: n/a
 
      04-22-2012
Hacker <(E-Mail Removed)> writes:

> On 2012-04-22 08:09:41 +0000, Martijn Lievaart said:
>
>> On Sun, 22 Apr 2012 10:03:26 +0200, Hacker wrote:
>>
>>> On 2012-04-22 06:11:26 +0000, Hacker said:
>>>
>>>> I have a little Perl program here:
>>>>
>>>> #!usr//bin/perl print "Hello World";
>>>>
>>>> it is called 'test'.
>>>>
>>>> When I write 'perl test' on the command line it works fine and comes
>>>> out with 'Hello World' just as it should, but when I write 'test' on
>>>> the command line there is no output.
>>>>
>>>> What is wrong.
>>>
>>> Considering I had written #!usr//bin/perl right as #!/usr/bin/perl but
>>> that is corrected now and there is still no output when you 'execute'
>>> the file.
>>>
>>> Any real dogs out there, or am I a moron.

>>
>> You are executing the test binary. Do a which test to see what you are
>> executing,or use ./test to start your own script.
>>
>> M4

>
> Cool, but I did not understand a thing


By default your current directory is not in the shell search path for
executables. So if you execute 'test' from a shell prompt, the shell
will search its path (held in the $PATH environment variable) to search
for an executable named test. As it so happens, there is an executable
named test in the path, and it lives in /bin.

If you want to execute something from your current directory, you have
to provide an explicit path to it. The way to do that is to prepend ./
to it, or to give an absolute path from the root.

Mart

--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
 
Reply With Quote
 
 
 
 
Mart van de Wege
Guest
Posts: n/a
 
      04-22-2012
Mart van de Wege <(E-Mail Removed)> writes:

>
> By default your current directory is not in the shell search path for
> executables. So if you execute 'test' from a shell prompt, the shell
> will search its path (held in the $PATH environment variable) to search
> for an executable named test. As it so happens, there is an executable
> named test in the path, and it lives in /bin.


And as someone else helpfully pointed out, 'test' is not even in the
path, it's a shell built-in.

Meh. My mistake.

As for your other question, don't edit .bashrc to add the current
directory to $PATH. That's a security risk. Just use ./ or copy your
script to a directory in $PATH.

Mart

--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
 
Reply With Quote
 
Tim McDaniel
Guest
Posts: n/a
 
      04-22-2012
In article <(E-Mail Removed)>,
Ben Morrow <(E-Mail Removed)> wrote:
>
>Quoth Mart van de Wege <(E-Mail Removed)>:
>> Mart van de Wege <(E-Mail Removed)> writes:
>>
>> > By default your current directory is not in the shell search path
>> > for executables. So if you execute 'test' from a shell prompt,
>> > the shell will search its path (held in the $PATH environment
>> > variable) to search for an executable named test. As it so
>> > happens, there is an executable named test in the path, and it
>> > lives in /bin.

>>
>> And as someone else helpfully pointed out, 'test' is not even in
>> the path, it's a shell built-in.

>
>This is not necessarily the case. POSIX /bin/sh has neither test nor
>[ built in, and therefore relies on them existing as executables in
>/bin. Many modern shells do provide them as builtins, and many
>(most? all?) modern systems install one of these shells as /bin/sh,
>though,


A bad practice that I've seen decryed. If you have a script that
depends on some feature of the original Bourne shell, or strict POSIX
compatibility, it's really nasty to have /bin/sh be something else.

Better, and I think (or at least hope more common) is to simply
provide a different login shell. For example, on my ISP,

tmcd:*:<uid>:<gid>:Tim McDaniel:<home directory>:/usr/local/bin/bash

>so it's likely you will see them as builtins.


And if not, as /bin/test and such -- and "." may yet be in your PATH
but at the end, so that /bin is hit first. I don't ever put "." in
PATH because it's a security hole on multi-user systems.

All this is a lot of detail. Short form:
- don't name a test program "test"
- invoke your own test programs with a path like ./foo or ~/foo
or /home/login/foo

--
Tim McDaniel, http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Martijn Lievaart
Guest
Posts: n/a
 
      04-22-2012
On Sun, 22 Apr 2012 17:27:38 +0000, Tim McDaniel wrote:

> A bad practice that I've seen decryed. If you have a script that
> depends on some feature of the original Bourne shell, or strict POSIX
> compatibility, it's really nasty to have /bin/sh be something else.


All serious bourne like shells emulate a POSIX sh if called as sh.

> Better, and I think (or at least hope more common) is to simply provide
> a different login shell. For example, on my ISP,
>
> tmcd:*:<uid>:<gid>:Tim McDaniel:<home directory>:/usr/local/bin/bash


Bash called as bash, all bash goodies available. On most systems I know /
bin/sh is either a symlink or a hardlink to ksh or bash. If you feel that
is a problem, you have a lot of vendors to convince.

M4
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      04-22-2012
(E-Mail Removed) (Tim McDaniel) writes:
[...]
> All this is a lot of detail. Short form:
> - don't name a test program "test"
> - invoke your own test programs with a path like ./foo or ~/foo
> or /home/login/foo


Good advice, but ...

*If* you carefully keep "." out of your $PATH *and* develop the
habit of invoking commands in the current directory as "./whatever",
then naming your own test program "test" isn't a problem.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Peter J. Holzer
Guest
Posts: n/a
 
      04-25-2012
On 2012-04-22 18:47, Ben Morrow <(E-Mail Removed)> wrote:
> Quoth Martijn Lievaart <(E-Mail Removed)>:
>> On Sun, 22 Apr 2012 17:27:38 +0000, Tim McDaniel wrote:
>>
>> > A bad practice that I've seen decryed. If you have a script that
>> > depends on some feature of the original Bourne shell, or strict POSIX
>> > compatibility, it's really nasty to have /bin/sh be something else.

>
> Relatively few systems use a true Bourne shell any more, since it isn't
> freely available. About the closest is ash, which has test(1) built in.
>
>> All serious bourne like shells emulate a POSIX sh if called as sh.

>
> Not to the extent of not providing test as a builtin:


Quoting from IEEE Std 1003.1â„¢-2008:

| An implementation may choose to make any utility a built-in

POSIX doesn't require test to be built-in, but it certainly allows it.
So ash is POSIX compatible in this regard.


> Debian and all (I think) of the BSDs use ash as /bin/sh, which was
> explicitly written to be a POSIX /bin/sh with minimal extensions.
> Solaris appears to use a derivatve of the original Bourne shell, with
> job control but without kshish POSIX features like $().


A /bin/sh which is missing POSIX features is worse than one which has
some extensions.

hp


--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | (E-Mail Removed) |
__/ | http://www.hjp.at/ | -- Bill Code on (E-Mail Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Perl on a Mac - again Peter Makholm Perl Misc 2 04-22-2012 11:43 AM
Re: Perl on a Mac - again Jürgen Exner Perl Misc 0 04-22-2012 11:34 AM
Re: Perl on a Mac - again Dr.Ruud Perl Misc 1 04-22-2012 08:52 AM
Activestate Perl and original Perl both on Mac OS Tiger Jake Wiley Perl Misc 14 06-16-2005 10:47 PM
jserve booting again and again amit Java 0 10-02-2003 04:26 PM



Advertisments