https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255144
Bug ID: 255144
Summary: /bin/sh: inconsistency between implementation and
manpage
Product: Base System
Version: 13.0-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: [email protected]
Reporter: [email protected]
sh(1) states about the use of alias:
alias [name[=string] ...]
If name=string is specified, the shell defines the alias name
with value string. If just name is specified, the value of the
alias name is printed. With no arguments, the alias built-in
command prints the names and values of all defined aliases (see
unalias). Alias values are written with appropriate quoting so
that they are suitable for re-input to the shell. Also see the
Aliases subsection.
So I would expect that only the value is printed when asking for it. That does
not seem to be the case. Actually also the assignment is being printed:
$ alias l
l='ls -laFG'
$
Further the output should be suitable for being fed back into the shell. That
is true but actually will create a shell variable assignment in the sub-shell.
That might be the intended behavour but IMHO is an odd deviation of /bin/sh's
alias/variable logic:
$ alias l | sh
$
Linux bash behaves differently, it also outputs the "alias" command before
printing name and value, so that this can be fed into a sub-shell as a command,
effecting the same result.
bash# alias vi
alias vi='vim'
bash#
Actually what I would like to achieve is something like this:
$ alias l | batch
which would be possible if our /bin/sh would simply print the value, as claimed
by the manpage. (Of course the 'l' example is not very much sensible, but think
of more complex alias incantations with command sequences to be submitted into
a batch run.)
Would it make sense to align our /bin/sh code with what the manpage states? The
diff is trivial...
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
