Re: Perl on a Mac - again

Discussion in 'Perl Misc' started by Martijn Lievaart, Apr 22, 2012.

  1. 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
    Martijn Lievaart, Apr 22, 2012
    #1
    1. Advertising

  2. Hacker <> 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.
    Mart van de Wege, Apr 22, 2012
    #2
    1. Advertising

  3. Mart van de Wege <> 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.
    Mart van de Wege, Apr 22, 2012
    #3
  4. Martijn Lievaart

    Tim McDaniel Guest

    In article <>,
    Ben Morrow <> wrote:
    >
    >Quoth Mart van de Wege <>:
    >> Mart van de Wege <> 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,
    Tim McDaniel, Apr 22, 2012
    #4
  5. 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
    Martijn Lievaart, Apr 22, 2012
    #5
  6. (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) <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"
    Keith Thompson, Apr 22, 2012
    #6
  7. On 2012-04-22 18:47, Ben Morrow <> wrote:
    > Quoth Martijn Lievaart <>:
    >> 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.
    | | | |
    __/ | http://www.hjp.at/ | -- Bill Code on
    Peter J. Holzer, Apr 25, 2012
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. amit
    Replies:
    0
    Views:
    372
  2. che
    Replies:
    2
    Views:
    475
  3. Dr.Ruud

    Re: Perl on a Mac - again

    Dr.Ruud, Apr 22, 2012, in forum: Perl Misc
    Replies:
    1
    Views:
    543
    Dr.Ruud
    Apr 22, 2012
  4. Peter Makholm

    Re: Perl on a Mac - again

    Peter Makholm, Apr 22, 2012, in forum: Perl Misc
    Replies:
    2
    Views:
    532
    Jürgen Exner
    Apr 22, 2012
  5. Jürgen Exner

    Re: Perl on a Mac - again

    Jürgen Exner, Apr 22, 2012, in forum: Perl Misc
    Replies:
    0
    Views:
    565
    Jürgen Exner
    Apr 22, 2012
Loading...

Share This Page