Problem in ksh - under HP-UX - displaying the value of $ERRNO

[Max Lee_1]

A trivial problem? I thought so:(
If anyone can help I'd be grateful as I've wasted too much time on it already

The man page says 'ERRNO holds the error number of the last system call that failed.'

So $>cp xxx yyy
$>echo $ERRNO
ought to display 2 when the file xxx does not exist? sometimes it does!
And sometimes it's 10, and sometimes 0.

I'm trying to log shell script errors in a database and had thought that a logging function passed $ERRNO by a trap ERR, would work but it appears unreliable. I've used 'echo' instead of the function here

$> trap 'echo $ERRNO' ERR
$>trap
46:echo $ERRNO
$>cp xxx yyy
cp: cannot access xxx: No such file or directory
10
$>

I can find many online examples using trap...ERR and $LINENO, which is also useful to me, but nothing regarding $ERRNO.

Is this an HP-UX foible, I'm sure I've used it before, but 20 odd years of this stuff and it seems Unix still has the capacity to surprise.

[James R. Ferguson]

Hi:

I don't thing the shell environmental variable 'ERRNO' is going to represent anything useful. You are confusing the return (exit) value (e.g. a '2' from 'cp') and a true error number set by a failed system function call.

Too, 'errno(2)' returned by a function call (when documented) isn't cleared by another succesful function call.

Regards!

...JRF...

[Dennis Handly]

>JRF: I don't think the shell environmental variable 'ERRNO' is going to represent anything useful.

Only if you use the shell properly and look at shell errors. :-)
$ ERRNO=09
$ < XXX > /dev/null
ksh[2]: XXX: cannot open
$ echo $ERRNO
2

[Steven Schweda]

"man ksh":

[...]
ERRNO The value of errno as set by the most recently
failed system call. This value is system
dependent and is intended for debugging purposes.
[...]

I read this as "for debugging" ksh itself
when _it_ gets a failure calling some system
function. The "errno" value in any program
like "cp" would evaporate when the "cp"
process exits. So far as I know, there's no
mechanism (other than the exit status) to
pass that kind of info back up to the shell.

> [...] I'm sure I've used it before [...]

Perhaps, but I don't see how it could have
done what you seem to think it did. (Which
is not an impossibility proof, of course,
but, as I say, I don't see how it could do
it.)

[Max Lee_1]

James,
Can't help feeling faintly insulted that you think I'm confused. I'm well aware of the existence and purpose of the return value of commands in ksh, as provided by $?. But, since that has its limitations, I was seeking to augment it with something that pointed to the cause of the error.

Dennis, Steven,
Your replies at least lead me to a different interpretation of the documentation. And if I was confused at all, then perhaps it was between 'system call' and 'command'.

It does seem a bit pointless documenting it though if it only works within the 'ksh' executable itself, and it doesn't really explain the occasional presence of the value '2' following the original example, or the very changeability itself within a single ksh session. If it's only changed when a true system call within ksh itself encounters an error then what is sometimes changing the value to '2', i.e. 'No such file or directory', or 0, i.e. no message at all, each again in the original example.

[James R. Ferguson · Accepted solution]

Hi (again) Max:

> James, Can't help feeling faintly insulted that you think I'm confused. I'm well aware of the existence and purpose of the return value of commands in ksh, as provided by $?.

I'm sorry. I meant no insult with my careless words. Please accept my apology. I think Dennis has showed us both how the shell will track (via ERRNO) the 'errno()' returned from a failed system call. Thanks for the insight, Dennis.

Regards!

...JRF...

[Dennis Handly]

>Your replies at least lead me to a different interpretation of the documentation.

It probably should have said debugging the shell.

>It does seem a bit pointless documenting it though if it only works within the 'ksh' executable itself

It says system-dependent and is probably required by posix?

>If it's only changed when a true system call within ksh itself encounters an error then what is sometimes changing the value to '2'

You can set ERRNO to some other value to help you check.

Also, 10 comes from ECHILD 10, probably something the shell does for process control.

[Max Lee_1]

Thanks All, for your help and information.