Re: A very interesting sed question

Stephane Chazelas wrote:

> sed '
> s,^,:,
> s,:/usr[^:]*,,g
> s,^$,/non-existent,
> s,^:,,'
>
> note that an empty PATH contains one entry: the current
> directory. So you need to have PATH=/non-existent ifever you
> remove all the entries. ("/usr/local/bin:" should be changed to
> "" (the current directory), and "/usr/local/bin" to
> "/some-inexistent-dir").

According to SUSv3 the behaviour for an empty PATH can vary
between implementations, so you can't rely on it meaning the
current directory. ("/usr/local/bin:" should be changed to
either ":" or "." to ensure the current directory is searched).

I was surprised that ksh88 treats an empty PATH as meaning the
current directory - I had assumed it would be treated the same
as an unset PATH (which causes it to use a default search path
of "/bin:/usr/bin:").

As far as I can tell, ksh93 doesn't do any path search when PATH
is empty. When PATH is unset it uses a default search path
(which the man page says is "/bin:/usr/bin:", but actually seems
not to include the current directory so is probably just
"/bin:/usr/bin").

At least bash is consistent (it treats empty and unset both as
meaning the current directory).

--
Geoff Clare

Re: A very interesting sed question

On Thu, 31 Jan 2008 14:25:05 +0000, Geoff Clare wrote:
> Stephane Chazelas wrote:
>
>> sed '
>> s,^,:,
>> s,:/usr[^:]*,,g
>> s,^$,/non-existent,
>> s,^:,,'
>>
>> note that an empty PATH contains one entry: the current
>> directory. So you need to have PATH=/non-existent ifever you
>> remove all the entries. ("/usr/local/bin:" should be changed to
>> "" (the current directory), and "/usr/local/bin" to
>> "/some-inexistent-dir").
>
> According to SUSv3 the behaviour for an empty PATH can vary
> between implementations, so you can't rely on it meaning the
> current directory. ("/usr/local/bin:" should be changed to
> either ":" or "." to ensure the current directory is searched).

and "/usr/local/bin" should not be changed to "".

> I was surprised that ksh88 treats an empty PATH as meaning the
> current directory - I had assumed it would be treated the same
> as an unset PATH (which causes it to use a default search path
> of "/bin:/usr/bin:").
>
> As far as I can tell, ksh93 doesn't do any path search when PATH
> is empty. When PATH is unset it uses a default search path
> (which the man page says is "/bin:/usr/bin:", but actually seems
> not to include the current directory so is probably just
> "/bin:/usr/bin").
>
> At least bash is consistent (it treats empty and unset both as
> meaning the current directory).
[...]

Actually, I had done some comparisons some time ago, but I don't
remember the details, you may find some article about it in
c.u.s. That behavior I remembered I think was based on
observation of the execvp(3) function. The default PATH varies
from system to system libc to libc (even version to version,
some older versions of the glibc even had the current directory
in front!), shell to shell... Some shells (bash, zsh,
modern-ash, pdksh) even define it upon startup if they don't
find it in their environment.

--
Stephane