bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15157: join doesn't follow norms and dies instead of doing something


From: Pádraig Brady
Subject: bug#15157: join doesn't follow norms and dies instead of doing something useful w/duplicate options
Date: Thu, 22 Aug 2013 04:55:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2

On 08/21/2013 10:44 PM, Linda Walsh wrote:
> 
> join is inconsistent with other utils (like cut, for example) in how
> it handles a specification of a switch value that has already been
> set.
> 
> 1) if a switch is set more than once with the same value, it
> doesn't complain, but if the options differ, unlike utilities
> like 'cut', the tool dies rather than taking the final
> specification as what is meant.
> 
> ex:
>    cut -d'<TAB>' -d: -f1 </etc/passwd
> doesn't issue any errors.

nor does `numfmt -d`

> But the same thing with join:
> join -t'<TAB>' -t: -f1 /etc/passwd /etc/group
> join: incompatible tabs
> 
> ???  tabs?  they are field separators.

I agree, the error is badly worded.
Note also that `sort -t` follows the `join` behavior.

> Historically, options specified on the command line take precedence
> over options in an init/rc-file or in the ENV.  Many utils
> in a build process build up command lines in pieces -- with the
> expectation that later values take precedence, allowing for
> higher level make files to set defaults, while allowing make's
> in sub directories to override options set in a parent.
> 
> Defaulting to "fail", rather than proceed with latest input
> data, is rarely useful for humans.  It's arguable whether or
> not it is useful for machines in most cases.
> 
> In the past, unix utils have tried to do what the user meant
> rather than deliberately playing "stupid" and pretending to have
> no clue about what was likely expected.

Right, to support subsequent specification of scripts etc.
it's useful to allow options to be overridden.
In addition this is how other systems behave wrt to
input field separator options for example.

Now on the other hand, the ambiguity being diagnosed here
in such an obtuse manner, is that one might think that _any_
of the specified separators are supported in the input,
rather than the last taking precedence.

So it is debatable as to whether this should be changed.
The utilities should at least be consistent with each other,
and if possible other systems. So in this case I'm inclined
to allow multiple field sep options and document that
the last takes precedence.

New users of these tools may be caught out though.
We could display a warning but that would negate most of
the benefit of allowing overriding the option.
I suppose we could support --debug on all utils to diagnose
ambiguities like this, rather than disallowing them.
I'll look at doing both of the above.

thanks,
Pádraig.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]