rclark@speclab.bgp-usgs.gov (Roger N. Clark) (11/28/89)
A user recently complained about a cryptic error message in unix (so
what else is new?). He did something like:
cp mydir/* /d36
Well, cp comes back with:
Usage: cp f1 f2
cp [-r] f1 ... fn d1
He was using it correctly but /d36 didn't exist. The message should
have been something like: "ERROR: destination directory does not exist."
A sun gave a similar usage message so this seems to be generic unix.
Could someone in the Unix standards area see if cp could be changed
to give reasonable error messages. How about the rest of Unix?
Roger N. Clark
..!speclab!rclarkrer@hpfcdc.HP.COM (Rob Robason) (12/01/89)
> Could someone in the Unix standards area see if cp could be changed > to give reasonable error messages. How about the rest of Unix? Roger, The problem seems to be that UN*X has been around long enough that people EXPECT it to misbehave in this way and have all kinds of brain dead scripts written which assume the cryptic message. Attempts to fix these at HP have often led to complaints. One I remember someone here fixing was "Don't grok 'something-or-other'": I was pleased to see it changed to english, but there were those UN*X bigots who thought it blasphemous. The real risk is that some officially sanctioned validation suite (NIST's for example 1/2 :-) will test the messages and fail for non conformance! Then our ability to claim standards conformance would be shot down. We've been discussing in an internal notes discussion the pros and cons of changing the perror() messages and have stumbled on the same issue. One possible solution is to use X/OPEN NLS (Internationalization, I18N for short) and provide american language messages for those who choose LANG=american, while the bigots can stick with the default C language. Rather than have everyone do this N times, hopefully OSF will provide a set of NLS commands (and perhaps even distribute contributed message catalogues for various languages) so everyone can get uniform, clear messages. Rob Robason
tbc@hp-lsd.COS.HP.COM (Tim Chambers) (12/02/89)
In our lab, a wise software project manager recently made a proclamation something to the effect: "The specification is frozen. All requests for changes to this project's library of functions are hereby forever denied. Defects will be repaired when the behavior of the functions deviates from the published specification. If it isn't part of the specification, the behavior will not change under *any* circumstances. Worthy enhancements will be accommodated by created new, unique functions." I was taught the same policy in college. I agree with it. Others have pointed out the unexpected pitfalls with '"improving" the UN*X out of UN*X.' IMHO, old commands should be left alone and new ones should take over. I hope we aren't doomed to always have a name with historical baggage, like awk and nawk or less replacing more(1). sh(1) vs. ksh(1) is an excellent example -- all my scripts now start with #!/bin/ksh. Much cleaner than "improving" the Bourne shell.
rclark@speclab.bgp-usgs.gov (Roger N. Clark) (12/05/89)
I see and understand the points made by Rob Robason and Tim Chambers. However, as a Unix fan trying to get others to change to unix, all efforts at conversion are useless when the convertees see stuff like this. Geez, they thought cp for copy was cryptic! When they error message is worse (even technically wrong in this case), they will never try. OK so how about a new unix command: "copy" that gives real error messages. Actually, I like the solution of language=american that would fix the error messages. But how many shell scripts will that break? Roger
burzio@mmlai.UUCP (Tony Burzio) (12/11/89)
In article <210039@speclab.bgp-usgs.gov>, rclark@speclab.bgp-usgs.gov (Roger N. Clark) writes: > OK so how about a new unix command: "copy" that gives real error > messages. Actually, I would be satisfied with a cp that allows unlimited numbers of files to be passed in. I had a directory with several hundred files that I wanted to copy, and a (cp * dir) gave me an error that there were too many parameters. The cp worked on a Sun, which is what I used over the NFS network to make the copy... ********************************************************************* Tony Burzio * Bugs bugs bugs... We need a program Martin Marietta Labs * called Orkin (TM) :-) mmlai!burzio@uunet.uu.net * *********************************************************************
rer@hpfcdc.HP.COM (Rob Robason) (12/12/89)
> Actually, I like the solution of language=american that would fix > the error messages. But how many shell scripts will that break? Unknown, but the workaround would then be trivial: modify the script by setting LANG= to use the default messages. > Roger Rob
rer@hpfcdc.HP.COM (Rob Robason) (12/14/89)
# DRIFTING A BIT > Actually, I would be satisfied with a cp that allows unlimited numbers > of files to be passed in. I had a directory with several hundred files > that I wanted to copy, and a (cp * dir) gave me an error that there were > too many parameters. Did the error actually come from cp, or from your shell? Shells are limited in the length of arguments they can expand to something like 10KB (some much less) and complain in situations like the one you describe. Rob Robason
davidb@Pacer.UUCP (David Barts) (12/15/89)
In article <627@mmlai.UUCP>, burzio@mmlai.UUCP (Tony Burzio) writes:
-> . . .
-> Actually, I would be satisfied with a cp that allows unlimited numbers
-> of files to be passed in. I had a directory with several hundred files
-> that I wanted to copy, and a (cp * dir) gave me an error that there were
-> too many parameters. The cp worked on a Sun, which is what I used over
-> the NFS network to make the copy...
Wouldn't help. It's the shell that expands wildcards, not cp. The shell
is overflowing the buffer it uses to hold expanded command strings.
The shell you used on the Sun either had a larger buffer or the length
of all file names in . was short enough to fit in the buffer. Try
`ls | xargs -i cp {} dir'. It's generally a bad idea to depend on the
shell always being able to expand `*'.
--
David Barts Pacer Corporation
davidb@pacer.uucp ...!fluke!pacer!davidb