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!rclark
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
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.
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
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!bur...@uunet.uu.net *
*********************************************************************
Unknown, but the workaround would then be trivial: modify the script
by setting LANG= to use the default messages.
> Roger
Rob
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
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
dav...@pacer.uucp ...!fluke!pacer!davidb