Alan Altmark wrote:
On Thursday, 10/13/2005 at 08:53 ZE8, John Summerfied
<[EMAIL PROTECTED]> wrote:
Are people happy that they will not be able to use these functions from
the commandline or from a shell script? The earlier suggestion (not
mine) was to do it in a posix shell.
But it doesn't make sense to have all of the diagnose functions available
from the command line anyway.
I won't ague against that, but I think some that have been highlighted
might be used so.
> And if a script greps stdout, and it
decides that the user should see the output, it can write the output back
to stdout itself. (I do this all the time in REXX execs - handle the
return codes I can deal with myself and dump to the console if I don't
recognize it. Is Linux so different?)
Most times, when I "grep" the output I do so in a pipe. I used the quote
because I also often use awk.
The result of grepping is usually that most of the output is discarded.
This illustrates my point without boring with the detail:
[EMAIL PROTECTED] ~]$ locate ~ | wc -l
114109
[EMAIL PROTECTED] ~]$ locate ~ | grep A | wc -l
3479
[EMAIL PROTECTED] ~]$
For those who don't know what's going on:
The tilde is replaced with the name of my home directory, so the locate
command produces a list of files in my home directory and its
subdirectories. wc as used just prints the number of lines.
The grep command eliminates all those files without an "A" in the path
name, so there are around 111000 files removed from the report.
I'm betting that many people will not take the added steps needed to
ensure users actually see what the progam said. What they need to do us
domething like this:
vmcp | tee /tmp/reportfile
or
vmcp 2>/tmp/reportfile
cat /tmp/reportfile
and then grep the report file. As you can see, it's more involved. For
my own purposes I'm often prepared to discard most of the report, but
it's not always appropriate and it looks to me like an accident waiting
to inconvenience.
That is why I proposed writing the return code to a separate file
(descriptor). Someone using it from the commandline can see the results
which, presumably, describe what happened and ignore the descriptor (the
write will simply fail) while a script-writer can capture it by
redirection, possibly as I described earlier.
vmcp is a Linux command interface to a CP command interface (diag 8). The
rest of the diagnose functions are programming interfaces of one sort or
another. This isn't some new limitation being proposed; this is inherent
in the limitations of the [e.g. bash] shell scripting language, is it not?
I can certainly envision some userspace apps in the package that do common
things with those diags, making them useful in a command environment, but
I don't think we need a command interface to the diags themselves.
Integrate some into /proc and others into /dev. Add the userspace apps on
top.
Rob's analysis seemed right on the money to me.
Alan Altmark
z/VM Development
IBM Endicott
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
Cheers
John
-- spambait
[EMAIL PROTECTED] [EMAIL PROTECTED]
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
do not reply off-list
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
