standard out and standard error

standard out and standard error

Post by Brad Slavi » Fri, 03 May 1996 04:00:00

I have a question based on 'unix etiquette as it were'

question as follows

I am involved in the development of a text parsing utility for a large
product, (unix platform)... I have several options when dealing with standard
out and standard error...

1) output both standard responses and errors to standard out and errors to
standard error

2) output normal responses to standard out and errors to standard error giving
the line number of the input file that the error occured on...

which is the accepted solution?

   -Brad Slavin

Unix QA Engineer
Asymetrix Corp


standard out and standard error

Post by Lou » Sun, 05 May 1996 04:00:00

As a systems admin, I prefer programs that send errors to
std err, and ONLY regular output to stdout.  This helps
when piping commands, running cmds in wrapper scripts that
do things with the output, create error logs, etc.  At
least DOCUMENT what you decide to do, so that I know what
to expect.  For example, grep returns nothing when there is no
match, so I can do `grep string myfile > junk`. I can now process junk,
because I know what the -input data looks like- (programming 101).
It either is empty, or contains "string"  I can wc -l,or  if -f junk,
etc.  I would get really screwed up if junk contained
"there were no occurances of 'string' in file 'myfile'"



1. LCSDNYR 2001 -> standards, standards, standards

[snip - a call for standardisation]

I completely agree, but I don't think Linux is going the wrong way (yet).

As always, tarballs (./configure, make, su -c 'make install') stay (oh yes
they will). Package-like installing (cfr deb, rpm, jbl, ...) goes the
right way: easy, user-friendly and without any hassle. I don't think it's
necessary to evolve to one package. Each type of packaging has it
advantages and disadvantages. It's a choice, a mindgame if you will. Some
people like the deb-packages since they are extremely easy to install.
Some others want rpm, since the availability of those files is enormous.
Some people stay with the tarballs.

I don't think Linux is going the wrong way.

With packages without any hassle. With tarballs you should look at the
Makefile before 'make install'-ing and search for 'make uninstall'. If
that's available (and correctly programmed), there isn't any other hassle.

This could be one point of discussion (tarballs - uninstalling software),
but I don't know enough about tarballs (I only use them if I can't find
any rpm-files for it) so I'd better shut up :-/

Again, with packages no troubles. Tarballs are also without any hassle,
since upgrading is very simpel. Configuration-files stay (thus not the way
M$ handled things, i.e. registry), binaries get upgraded, libraries are
... how do they say it... renewed? I mean, a newer version of library
doesn't overwrite things (f.i., only has a greater
version-number (f.i. And ldconfig makes sure programs
use the right library...

/etc/*.conf, $HOME/.*rc, ... I think Linux (and most unix-like OS'ses) are
doing a great job on that. They are easy to back-up, easy to modify
(manually AND with scripts/tools), ...


2. OpenOffice Installation from ports

3. redirecting standard output and standard error

4. virtual domains :)

5. differentiate between standard output and standard error?

6. what about an integrated development enviroment on free(gnu)pascal?

7. standard out and standard error questions

8. tips

9. capturing standard error info but not standard out

10. How to redirect standard error to standard output (in csh)?

11. System V standard vs. BSD standard -> where to find?

12. No standard GUI, but standard metaphors!

13. Standard Question about Standard Files.