«

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

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 <> 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.

In article <5ked69->,
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,

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

(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) kst- <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"

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