reopen 395368 !
thanks
> > It's a classic design disagreement, ...automobile safety belts...
> > ...Jack Williamson's 'Humanoid' stories...
> I find these comparisons to be totally out of the scope of the issue
> we're discussing.
Culture clash. Who's culture or what region's customs determines the "proper"
surrounding scope?
> > ...If error messages and consistent output in
> > response to unexpected data are a "feature" you never intended and
> > don't wish to implement, then change this bug's severity to
> > "wishlist" and tag it "wontfix". ...
>
> Fine, I'll keep the program as-is. I'm tagging the bug as you wish but
> am also closing it, there's no need to keep it open. ...
This is an interesting bug. Most users would probably agree that
processing the letter 'z' as a '0' without notice is an obvious bug.
Yet I can see the mathy point of view, you'd call the 'z' undefined
input outside the domain of a function. In low level languages like
'Forth' that sort of function is common practice, but in higher level
command line utils "garbage in, garbage out" is bad form. Where to
draw the line between GIGO and error catching, or freedom and safety?
The public good of keeping a bug open as a 'wontfix' is so BTS readers
see the bug is contentious. If it's closed, readers might suppose there
was some mutually satisfactory agreement.
My own prejudice, look around at what other utils do:
expr 2 + 2z
expr: non-numeric argument
printf "%i\n" 2z
bash: printf: 2z: invalid number
0
/usr/bin/printf "%i\n" 2z
/usr/bin/printf: 2z: value not completely converted
2
dmesg | tail -n 2z
tail: 2z: invalid number of lines
seq 10z
seq: invalid floating point argument: 10z
Try `seq --help' for more information.
numrange /1..10z/
Invalid expression: 1..10z
dmesg | grep -m 1z bin
grep: invalid max count
Etc...
PS: 'Forth' guru Leo Brodie advises that the way to avoid user troubles
with functions without error messages is with stricter input routines
that prevent the user entering bad data, then errors never occur;
e.g. if you prompt for a number, ignore any key that's not a
number. Nip it in the bud! Good idea. Alas, for piped input that's
impossible, but it seems theoretically possible for a clever shell key
parser to do that with command line parameters. If the 'i' program was
modified to run under such a hypothetical shell, it would be fine as
is, since the shell would know the correct parameter syntax and the
user would be unable to type ' 2z', they'd enter the ' 2', but the 'z'
key wouldn't type anything.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
