I installed the posix-only shell (posh). To my surprise, it
does not have the 'type' builtin. What, 'type' is not posix ?

How one is supposed to check that command X is available in posix-only
shell ?

Yakov

2006-11-8, 03:40(-08), Yakov:
> I installed the posix-only shell (posh). To my surprise, it
> does not have the 'type' builtin. What, 'type' is not posix ?

Yes, type is POSIX, that's probably a bug in posh or in your
posh installation.

> How one is supposed to check that command X is available in posix-only
> shell ?
[...]

You can also try command -v cmd (which is Unix if not POSIX).

--
Stéphane

2006-11-8, 11:48(+00), Stephane CHAZELAS:
> 2006-11-8, 03:40(-08), Yakov:
>> I installed the posix-only shell (posh). To my surprise, it
>> does not have the 'type' builtin. What, 'type' is not posix ?
>
> Yes, type is POSIX, that's probably a bug in posh or in your
> posh installation.
[...]

Actually, talking with the posh maintainer and after double
check, type seems not to be POSIX, it's an XSI extension.

That means that there doesn't seem to be any way for a POSIX
script to know whether a command exists.

Any clue anyone why "type" was left out? According to Sven's
page, it seem to have been in the Bourne shell since SVR2 and
surely it was in ksh from the start. ash didn't have it
originally though.

--
Stéphane

Stephane CHAZELAS wrote:

> [...] type seems not to be POSIX, it's an XSI extension.
> [...] it seem to have been in the Bourne shell since SVR2 and
> surely it was in ksh from the start. ash didn't have it
> originally though.

I don't know the reason - but I'm really afraid the respective
implementors considered the command only to be useful for "debugging".

2006-11-8, 22:34(+01), Sven Mascheck:
> Stephane CHAZELAS wrote:
>
>> [...] type seems not to be POSIX, it's an XSI extension.
>> [...] it seem to have been in the Bourne shell since SVR2 and
>> surely it was in ksh from the start. ash didn't have it
>> originally though.
>
> I don't know the reason - but I'm really afraid the respective
> implementors considered the command only to be useful for "debugging".

That's a bit sad given that there's no POSIX way to look up for
a command manually given that when PATH is unset the shell's
behavior is mostly underfined.

I guess approximations like:

exists() {
case $1 in
*/*)
[ -f "$1" ] && [ -x "$1" ]
return
esac
(
IFS=:
p=$PATH:x
set -f
set -- $p
for i do
[ "$#" -gt 1 ] || return 1
i=$i${i:+/}$cmd
[ -f "$i" ] && [ -x "$i" ] && return 0
done
)
}

would do in most cases (it doesn't report about
builtins/functions/aliases... though).

--
Stéphane

Stephane CHAZELAS wrote:
> > 2006-11-8, 03:40(-08), Yakov:
> >> I installed the posix-only shell (posh). To my surprise, it
> >> does not have the 'type' builtin. What, 'type' is not posix ?
>
> Actually, talking with the posh maintainer and after double
> check, type seems not to be POSIX, it's an XSI extension.
> That means that there doesn't seem to be any way for a POSIX
> script to know whether a command exists.
>
> Any clue anyone why "type" was left out?

Speculating; they rely on the existence of an external 'which' command?
(At least to find the shell external commands.)

> According to Sven's
> page, it seem to have been in the Bourne shell since SVR2 and
> surely it was in ksh from the start. ash didn't have it
> originally though.

Janis

2006-11-9, 02:06(-08), Janis:
> Stephane CHAZELAS wrote:
>> > 2006-11-8, 03:40(-08), Yakov:
>> >> I installed the posix-only shell (posh). To my surprise, it
>> >> does not have the 'type' builtin. What, 'type' is not posix ?
>>
>> Actually, talking with the posh maintainer and after double
>> check, type seems not to be POSIX, it's an XSI extension.
>> That means that there doesn't seem to be any way for a POSIX
>> script to know whether a command exists.
>>
>> Any clue anyone why "type" was left out?
>
> Speculating; they rely on the existence of an external 'which' command?
> (At least to find the shell external commands.)
[...]

Which used to be a csh script that read the ~/.cshrc (to find
out about the users $PATH and aliases) so was intended for csh
users only. It is still the case on most systems.

On others, it has been modified to support other shells (like
GNU which) but it is still a dirty hack.

which is builtin tcsh and zsh.

ksh and zsh have whence. zsh also has "where" (alias for which
-a, which being an alias for whence -c)

All modern shells but posh have type.

Old versions of the Bourne shell and Almquist shell (and
possibly Korn shell) have been known not to have "type".

It's true that on BSD, which was there before type, that may be
why people got used to using which even though it is broken
(except in tcsh and zsh).

--
Stéphane

Stephane CHAZELAS <this.address@is.invalid> wrote, on Wed, 08 Nov 2006:

>> I installed the posix-only shell (posh). To my surprise, it
>> does not have the 'type' builtin. What, 'type' is not posix ?
>
> Yes, type is POSIX, that's probably a bug in posh or in your
> posh installation.
>
>> How one is supposed to check that command X is available in posix-only
>> shell ?
> [...]
>
> You can also try command -v cmd (which is Unix if not POSIX).

You have it backwards: "type" is UNIX, "command -v" is POSIX.

--
Geoff Clare <netnews@gclare.org.uk>

2006-11-09, 14:11(+00), Geoff Clare:
> Stephane CHAZELAS <this.address@is.invalid> wrote, on Wed, 08 Nov 2006:
>
>>> I installed the posix-only shell (posh). To my surprise, it
>>> does not have the 'type' builtin. What, 'type' is not posix ?
>>
>> Yes, type is POSIX, that's probably a bug in posh or in your
>> posh installation.
>>
>>> How one is supposed to check that command X is available in posix-only
>>> shell ?
>> [...]
>>
>> You can also try command -v cmd (which is Unix if not POSIX).
>
> You have it backwards: "type" is UNIX, "command -v" is POSIX.
[...]

But "command -v" is required by XSI (Unix if I understand
correctly) and optionnal in POSIX.

| -v
| (On systems supporting the User Portability
| Utilities option.) Write a string to standard
| output that indicates the pathname or command that
| will be used by the shell, in the current shell
| execution environment (see Shell Execution
| Environment ), to invoke command_name, but do not
| invoke command_name.

| XSI Shell and Utilities Conformance
|
| * The system shall support all the utilities defined in the
| Shell and Utilities volume of IEEE Std 1003.1-2001 as
| part of the XSI extension denoted by
| the XSI marking in the SYNOPSIS section, and any
| extensions marked with the XSI extension marking (see
| Codes) within the text.
|
| * The system shall support the User Portability Utilities
| option.

If it's optional, that means a script can't use it.

And posh implements neither type nor command -v

--
Stéphane

Stephane CHAZELAS wrote:
> 2006-11-09, 14:11(+00), Geoff Clare:
> > Stephane CHAZELAS <this.address@is.invalid> wrote, on Wed, 08 Nov 2006:
> >
> >>> I installed the posix-only shell (posh). To my surprise, it
> >>> does not have the 'type' builtin. What, 'type' is not posix ?
> >>
> >> Yes, type is POSIX, that's probably a bug in posh or in your
> >> posh installation.
> >>
> >>> How one is supposed to check that command X is available in posix-only
> >>> shell ?
> >> [...]
> >>
> >> You can also try command -v cmd (which is Unix if not POSIX).
> >
> > You have it backwards: "type" is UNIX, "command -v" is POSIX.
> [...]
>
> But "command -v" is required by XSI (Unix if I understand
> correctly) and optionnal in POSIX.
>
> | -v
> | (On systems supporting the User Portability
> | Utilities option.) Write a string to standard
> | output that indicates the pathname or command that
> | will be used by the shell, in the current shell
> | execution environment (see Shell Execution
> | Environment ), to invoke command_name, but do not
> | invoke command_name.
>
> | XSI Shell and Utilities Conformance
> |
> | * The system shall support all the utilities defined in the
> | Shell and Utilities volume of IEEE Std 1003.1-2001 as
> | part of the XSI extension denoted by
> | the XSI marking in the SYNOPSIS section, and any
> | extensions marked with the XSI extension marking (see
> | Codes) within the text.
> |
> | * The system shall support the User Portability Utilities
> | option.
>
> If it's optional, that means a script can't use it.
>
> And posh implements neither type nor command -v

Yep, to allow optional extensions and not have command (like 'type')
to query their existance .... Created by the committee, what can I say.

Yakov

Stephane CHAZELAS <this.address@is.invalid> wrote, on Thu, 09 Nov 2006:

>> You have it backwards: "type" is UNIX, "command -v" is POSIX.

> But "command -v" is required by XSI (Unix if I understand
> correctly) and optionnal in POSIX.
>
> | -v
> | (On systems supporting the User Portability
> | Utilities option.) Write a string to standard
> | output that indicates the pathname or command that
> | will be used by the shell, in the current shell
> | execution environment (see Shell Execution
> | Environment ), to invoke command_name, but do not
> | invoke command_name.

This says -v is part of the User Portability Utilities (UP) option.

UP is a POSIX option. Thus "command -v is POSIX" (despite being
optional).

By contrast, "type" is marked XSI in the standard, thus "type is UNIX".

> | XSI Shell and Utilities Conformance
> |
> | * The system shall support all the utilities defined in the
> | Shell and Utilities volume of IEEE Std 1003.1-2001 as
> | part of the XSI extension denoted by
> | the XSI marking in the SYNOPSIS section, and any
> | extensions marked with the XSI extension marking (see
> | Codes) within the text.
> |
> | * The system shall support the User Portability Utilities
> | option.

This says that the POSIX UP option is mandated for XSI conforming
(i.e. UNIX) systems.

Several other POSIX options are also mandated for XSI conformance,
there is nothing unique about UP here.

> If it's optional, that means a script can't use it.

It means that a script which uses it assumes that the system
supports the UP option. So does a script that uses any of
these utilities:

csplit, df, du, ex, expand, file, more, nice, patch, ps,
renice, split, strings, time, tput, unexpand, uudecode,
uuencode, who

> And posh implements neither type nor command -v

Could be an oversight. Does posh implement other UP features
of the shell, such as alias, fc, fg/bg, or interactive command
line editing?

--
Geoff Clare <netnews@gclare.org.uk>

2006-11-10, 13:59(+00), Geoff Clare:
[...]
>> And posh implements neither type nor command -v
>
> Could be an oversight. Does posh implement other UP features
> of the shell, such as alias, fc, fg/bg, or interactive command
> line editing?
[...]

Nope, bare POSIX:

$ posh
$ alias a=f
posh: alias: not found
$ set -o vi
posh: set: vi: bad option
$ fc
posh: fc: not found
$ sleep 10 &
[1] 9098
$ fg
posh: fg: not found

--
Stéphane

Yakov wrote:
> I installed the posix-only shell (posh). To my surprise, it
> does not have the 'type' builtin. What, 'type' is not posix ?

> 2006-11-8, 11:48(+00), Stephane CHAZELAS:
>>Actually, talking with the posh maintainer and after double
>>check, type seems not to be POSIX, it's an XSI extension.

Ok, I did not realize that XSI vs POSIX difference.

'posh' shell does not have XSI ...

But then my original question [1] should have been "is there a strictly

XSI/POSIX only shell around, without bash/zsh/ksh extensions" ...
is there ?

Yakov

[1]
http://groups.google.com/group/comp....5a08d150402fa8
"strictly posix shell mode ?"

2006-11-11, 11:23(-08), Yakov:
> Yakov wrote:
>> I installed the posix-only shell (posh). To my surprise, it
>> does not have the 'type' builtin. What, 'type' is not posix ?
>
>> 2006-11-8, 11:48(+00), Stephane CHAZELAS:
>>>Actually, talking with the posh maintainer and after double
>>>check, type seems not to be POSIX, it's an XSI extension.
>
> Ok, I did not realize that XSI vs POSIX difference.
>
> 'posh' shell does not have XSI ...
>
> But then my original question [1] should have been "is there a strictly
>
> XSI/POSIX only shell around, without bash/zsh/ksh extensions" ...
> is there ?
[...]

Is there a point to that? Given that for instance neither bash,
ash nor many implementations of ksh are XSI conformant? So if
you write a script and this script works with that hypothetical
POSIX-XSI shell, that gives no guarantee that it will work
everywhere..

echo '\t' should output a tab in a XSI conformant shell. and
echo -n should output "-n". However, for a POSIX shell, the
behavior is unspecified in either case.

--
Stéphane