command -v ../foo when ../foo is a directory

command -v ../foo when ../foo is a directory

[Simon Josefsson]

[-- Attachment #1: Type: text/plain, Size: 675 bytes --]

Hi.

I noticed a (to me) unexpected difference between bash and dash, compare
bash behaviour:

jas@latte:~$ mkdir -p foo foo/bar
jas@latte:~$ cd foo/bar
jas@latte:~/foo/bar$ command -v ../bar
jas@latte:~/foo/bar$ echo $?
1
jas@latte:~/foo/bar$ 

with dash behaviour:

$ mkdir -p foo foo/bar
$ cd foo/bar
$ command -v ../bar
../bar
$ echo $?
0
$ 

That is, dash's 'command -v' return success on directories for relative
names.  I believe the dash behaviour is incorrect, but I'd appreciate if
someone else read the POSIX spec here.  Do you agree?

This is on Debian bullseye with dash 0.5.11+git20200708+dd9ef66-5 and
bash 5.1-2+deb11u1.

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

Re: command -v ../foo when ../foo is a directory

[Harald van Dijk]

On 16/08/2022 14:01, Simon Josefsson wrote:
> Hi.
> 
> I noticed a (to me) unexpected difference between bash and dash, compare
> bash behaviour:
> 
> jas@latte:~$ mkdir -p foo foo/bar
> jas@latte:~$ cd foo/bar
> jas@latte:~/foo/bar$ command -v ../bar
> jas@latte:~/foo/bar$ echo $?
> 1
> jas@latte:~/foo/bar$
> 
> with dash behaviour:
> 
> $ mkdir -p foo foo/bar
> $ cd foo/bar
> $ command -v ../bar
> ../bar
> $ echo $?
> 0
> $
> 
> That is, dash's 'command -v' return success on directories for relative
> names.

It's not relative vs absolute, it's because names that don't involve / 
involve PATH lookup. If you try 'command -v /', dash will also print /.

>         I believe the dash behaviour is incorrect, but I'd appreciate if
> someone else read the POSIX spec here.  Do you agree?

Sadly, I don't. I think the current behaviour is what POSIX technically 
requires, and at the same time that what POSIX requires is bad and shell 
authors should use common sense and not implement it as written.

POSIX says for command -v:

 > Utilities, regular built-in utilities, command_names including a 
<slash> character, and any implementation-defined functions that are 
found using the PATH variable (as described in Command Search and 
Execution), shall be written as absolute pathnames.

../bar is a command_name including a <slash> character. There is nothing 
in here that says to check whether it is executable, POSIX just says to 
write it as an absolute pathname, and that is what dash does.

Even if this text is read as deferring to Command Search and Execution, 
that says:

 > If the command name contains at least one <slash>, the shell shall 
execute the utility in a separate utility environment with actions 
equivalent to calling the execl() function [...]

There is no "check if it is an executable file" here either, the shell 
is supposed to just execl() the directory and report the error. And in a 
way, it kind of makes sense that command -v reports that that is what 
the shell would attempt.

Despite this, dash is pretty much the only shell that behaves this way 
and I would encourage changing it to match other shells.

> This is on Debian bullseye with dash 0.5.11+git20200708+dd9ef66-5 and
> bash 5.1-2+deb11u1.
> 
> /Simon

Cheers,
Harald van Dijk

Re: command -v ../foo when ../foo is a directory

[Simon Josefsson]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

Harald van Dijk <harald@gigawatt.nl> writes:

> POSIX says for command -v:
>
>> Utilities, regular built-in utilities, command_names including a
>   <slash> character, and any implementation-defined functions that are 
> found using the PATH variable (as described in Command Search and
> Execution), shall be written as absolute pathnames.
>
> ../bar is a command_name including a <slash> character. There is
> nothing in here that says to check whether it is executable, POSIX
> just says to write it as an absolute pathname, and that is what dash
> does.

Interesting, thank you!  It looks like a bug in the POSIX specs, perhaps
we can get it clarified?  Either by mandating a particular behaviour
going forward, or at least acknowledge the different interpretations
somehow.

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]