[GRLUG] Failing Firefox

[Raymond McLaughlin]

Ben Rousch wrote:
> "john-thomas richards" <jtr at jrichards.org> wrote:
>> On Mon, May 07, 2007 at 07:59:38PM -0400, Jason Kisner wrote:
>> The default in the world of Linux commands is to not output messages
>> unless the command failed.  In other words, when "nothing happened"
>> something did happen and so you were not told that something broke. 
>> In still more words, most commands will only indicate the command
>> failed, and will indicate nothing if the command worked.
>>
>> Wow.  Does that make any sense?
>> -- 
>> john-thomas
>> ------
> 
> It makes sense in the old Unix world where you know the programs you are using are well-written by competent programmers and will work most of the time. So in this case it makes sense to only let you know when something went wrong so you can quickly move on to other things.

In this case it is you, or your script, that can move on to other
things. Most *nix commands are simple and written with an eye toward
chaining them together into a script. If each command were verbose about
it's actions then your would need to add code to each step in your
script to deal with the output resulting from each step working
correctly. This is the main reason that screen output is only desirable
when there is an error.

On the other hand, most commands take a command line switch (often -v)
to increase verbosity if you want reassurance that the command worked as
you expected.

for example the diff command compares two files, and -s tells diff to
explicitly inform you if the files are the same:

    pts/1 $ cp a.txt b.txt
    pts/1 $ diff a.txt b.txt
no switch no output. If you want reassurance:
    pts/1 $ diff -s a.txt b.txt
    Files a.txt and b.txt are identical
    pts/1 $

In this case any difference found is sent to standard output (not stderr).

diff --help for more info.

Any clearer?


> In the Windows world you know that your programs are slapped together by the lowest bidder with Visual Basic and will almost never work as advertised. In this case it makes sense to let you know when things actually went right so you don't sit there waiting for the inevitable error message.

Though the command line environment exists in windoze, it is crippled
almost beyond use.

> No, I'm not bitter about some of the Windows programs we use at work. Not at all.
>