Re: [bug-ncurses] [PATCH 12/40] man/tput.1: Revise (1/10) (NAME, SYNOPSIS, DESCRIPTION introduction).

[G. Branden Robinson]

Hi Werner,

At 2024-01-16T08:35:00+0100, Dr. Werner Fink wrote:
> You need one point more for the manual page init(8) of SysVinit based
> systems I guess ;)
> 
>  INIT(8)        Linux System Administrator's Manual           INIT(8)
> 
>  NAME
>        init, telinit - process control initialization
> 
>  [...]

Not in this case, I think, because sections 8 and 1 are different.  This
aspect is like the "printf" example I shared earlier this week.

$ man -aw printf
/usr/share/man/man1/printf.1.gz
/usr/share/man/man3/printf.3.gz

> > I assume 2e would break compatibility on some System V vendor Unix
> > curses whose tput behaves in a similar way, and which ncurses has
> > enjoyed supplanting for decades.  As the tput(1) page notes, X/Open
> > did not standardize the _utilities_ of a Curses implementation
> > (including tput) until Issue 7 (2009), by which time the Unix Wars
> > were long over.
> 
> I'm a bit puzzled ... IMHO it makes a difference between the call of
> 
>   tput init
> 
> in comparision to a simple call of
> 
>   init
> 
> or
> 
>   telinit

I agree that all of these are different things, but $PATH always
matters.  If there is an "init" in both /usr/sbin and /usr/bin,
traditionally, unprivileged users will only access the latter from your
examples of shell input above, and "telinit" will likely result in
"command not found".

At the same time, $PATH has generally been user-configurable (except on
some nearly forgotten time-sharing environments using "restricted
shells" or similar).  Consequently, what a man page has to say is not a
reliable predictor of what level of privilege will be required/expected
by an unqualified command name typed at the shell prompt.

(On top of that, some man(1) programs support a user-configurable
$MANPATH, too, so the command lookup ordering might not match that of
the corresponding man pages.)

This is what I was trying to establish with my "Try it!" example earlier
this week.  A user can always create a $HOME/bin directory, put it first
in $PATH, and executables placed there will take priority.  And _that_
has nothing at all to do with what and where a system integrator elects
to install things.

All of this is why, in my opinion, a man page should document what _it_
supports, and not make assumptions about how $PATH or $MANPATH are
configured on the system.  "What _it_ supports" includes special
handling of argv[0].

If you were to claim that it's a bit weird for tput(1) and tset(1) to
change their behavior by inspecting their own argv[0], I would not
contradict you.  This used to be more common in Unix systems, but it
seems that over the decades, common practice has come to dance to a tune
the GNU Coding Standards have been calling since the 1990s (which may in
turn have been adapted from an even older source of conventional wisdom
unknown to me).

  4.5 Standards for Interfaces Generally

  Please don’t make the behavior of a utility depend on the name used to
  invoke it. It is useful sometimes to make a link to a utility with a
  different name, and that should not change what it does. Thus, if you
  make foo a link to ls, the program should behave the same regardless
  of which of those names is used to invoke it.

https://www.gnu.org/prep/standards/standards.html#User-Interfaces

I have a vague recollection that {grep,egrep,fgrep} used to be
implemented this way, with behavior changing with argv[0], and this led
to some grief, which is (I think) why POSIX instead mandated that grep
support `-E` and `-F` options instead to select the dialect of pattern
matching language.

> > 2c has, I would guess, similar distributor appeal, but freights
> > ncurses's "install" target, already complex and relatively slow,
> > with (another?) special case.  I worry about its maintainability
> > already.
> 
> Whereas tput, clear, and reset can be called on the command line the
> sub commands init and longname of tput can not due missing aliasing
> links to tput.

These claims are a bit muddled; you're mixing up the issues of
$PATH-availability and argv[0]-parameterized behavior.  Here's my "Try
it!" example again.

$ tput
[get usage message]
$ (cd ~/bin && ln -s /usr/bin/tput init)
$ type -p init
[verify that your symlink is found]
$ tput smso # "mess up" your terminal
$ init
[observe repaired terminal state and lack of usage message]
$ rm ~/bin/init

tput's "init" behavior is readily accessible, as you can verify for
yourself.  If you try the above with a link called "longname" instead of
"init", you will not get "tput longname" behavior, but a usage
message--because tput inspects its own argv[0] to decide how to behave.
There is no special casing for "longname", so tput performs its default
behavior, sees that it has no arguments, and complains.

> Also reset is linked to tset and currently clear is its own program.

These facts don't prevent the user from doing either of the following.

$ (cd ~/bin && ln -s /usr/bin/tput reset)
$ (cd ~/bin && ln -s /usr/bin/tput clear)

With that done (and "$HOME/bin" early in the $PATH, of course), the
things you say "cannot" be called, will be.

There would be no point documenting these alternative names in the
"NAME" sections of the tput(1) and tset(1) man pages if this were not
the case.  Anyone can give any command an alternative name.

$ (cd ~/bin && ln -s /usr/bin/tput mxyzptlk)

I hope this helps clarify matters.  Possibly the surprises arising from
argv[0]-parameterized behavior in commands are why organizations like
POSIX and GNU have exhorted against the practice.

Regards,
Branden

signature.asc
Description: PGP signature