From khogoboom at gmail.com  Wed Dec  1 21:41:58 2010
From: khogoboom at gmail.com (Karen Hogoboom)
Date: Wed, 1 Dec 2010 21:41:58 -0800
Subject: [buug] hello
In-Reply-To: <877hfyzncy.fsf@matica.localdomain>
References: <AANLkTimT0m2WWtkquJJsnuKbV2G1DM369cLG0Od+Jwge@mail.gmail.com>
	<877hfyzncy.fsf@matica.localdomain>
Message-ID: <AANLkTi=iwDFH2RRwJ+NfdCd4YvS3s-ca5ddpSznnv0T9@mail.gmail.com>

That is my new project for awhile then.

login [pam] -- I fail.  I don't know why there has to be a daemon for login.

-csh -- I fail.  Looks like a vararg or parameter or flag, not a process.

/bin/sh /usr/local/bin/startx -- I sort of get this, but am wondering I need
to be logged in as root if this computer is its own server, window manager
with its own clients.

oh, wait...ps -auxww... it's coming back to me.  My first Unix (is it
properly UNIX?) was Solaris.

I hope I'm not part of BOINK yet.

Karen


On Sat, Nov 27, 2010 at 9:29 AM, Ian Zimmerman <itz at buug.org> wrote:

>
> Karen> Do I want gnome or kde when I don't even want to *emulate* MS on
> Karen> this machine?
>
> No.
>
> Get a well-configurable window manager (examples: sawfish, windowmaker
> or openbox).  Don't install stuff until you need it.  You should
> understand (on a high level) what each line in the output of ps does.
> When you don't, you know you're nearing MS territory :-)
>
> --
> Ian Zimmerman <itz at buug.org>
> gpg public key: 1024D/C6FF61AD
> fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
> Ham is for reading, not for eating.
>



-- 
http://www.linkedin.com/in/karenlhogoboom
http://www.facebook.com/klhogoboom
http://boomtownbits.livejournal.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buug.org/pipermail/buug/attachments/20101201/ac622dec/attachment.html>

From itz at buug.org  Thu Dec  2 08:36:32 2010
From: itz at buug.org (Ian Zimmerman)
Date: Thu, 02 Dec 2010 08:36:32 -0800
Subject: [buug] hello
In-Reply-To: <AANLkTi=iwDFH2RRwJ+NfdCd4YvS3s-ca5ddpSznnv0T9@mail.gmail.com>
	(Karen Hogoboom's message of "Wed, 1 Dec 2010 21:41:58 -0800")
References: <AANLkTimT0m2WWtkquJJsnuKbV2G1DM369cLG0Od+Jwge@mail.gmail.com>
	<877hfyzncy.fsf@matica.localdomain>
	<AANLkTi=iwDFH2RRwJ+NfdCd4YvS3s-ca5ddpSznnv0T9@mail.gmail.com>
Message-ID: <878w08b08f.fsf@matica.localdomain>


Karen> That is my new project for awhile then.  login [pam] -- I fail.
Karen> I don't know why there has to be a daemon for login.

Not a daemon.  This is the same process that becomes your shell after
you log in.

Karen> -csh -- I fail. Looks like a vararg or parameter or flag, not a
Karen> process.

I said high level :)  You don't need to understand the flags.  Just what
it is and why it is running.  This is your shell (which used to be a
login process).  The leading dash is just a trick to make it know it is
in fact a login shell, and not just any random interactive shell that
you started by typing "csh".  But that is a detail that can wait for
much later.

Karen> /bin/sh /usr/local/bin/startx -- I sort of get this, but am
Karen> wondering I need to be logged in as root if this computer is its
Karen> own server, window manager with its own clients.

No, because the X server is setuid root.  setuid is kind of important
concept, maybe google it.

hth
-- 
Ian Zimmerman <itz at buug.org>
gpg public key: 1024D/C6FF61AD 
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
Ham is for reading, not for eating.


From Michael.Paoli at cal.berkeley.edu  Thu Dec  2 17:58:03 2010
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Thu, 02 Dec 2010 17:58:03 -0800
Subject: [buug] login [not] a daemon? ... & CDs
In-Reply-To: <878w08b08f.fsf@matica.localdomain>
References: <AANLkTimT0m2WWtkquJJsnuKbV2G1DM369cLG0Od+Jwge@mail.gmail.com>
	<877hfyzncy.fsf@matica.localdomain>
	<AANLkTi=iwDFH2RRwJ+NfdCd4YvS3s-ca5ddpSznnv0T9@mail.gmail.com>
	<878w08b08f.fsf@matica.localdomain>
Message-ID: <20101202175803.884907iax7aj71kc@webmail.rawbw.com>

> From: "Ian Zimmerman" <itz at buug.org>
> Subject: Re: [buug] hello
> Date: Thu, 02 Dec 2010 08:36:32 -0800

> Karen> That is my new project for awhile then.  login [pam] -- I fail.
> Karen> I don't know why there has to be a daemon for login.
>
> Not a daemon.  This is the same process that becomes your shell after
> you log in.

Well, ... depends a bit how one logs in, ... may or may not *directly* be
a daemon, ... but there would at least be inetd or xinetd or init somewhere
behind it ... it nothing else.  Has to be something that forks/execs that
shell or login/shell/process.

... 1 hr. to BUUG :-) ... oh, and I'll be bringing some CDs (Ubuntu & others).



From itz at buug.org  Thu Dec  2 20:50:52 2010
From: itz at buug.org (Ian Zimmerman)
Date: Thu, 02 Dec 2010 20:50:52 -0800
Subject: [buug] login [not] a daemon? ... & CDs
In-Reply-To: <20101202175803.884907iax7aj71kc@webmail.rawbw.com> (Michael
	Paoli's message of "Thu, 02 Dec 2010 17:58:03 -0800")
References: <AANLkTimT0m2WWtkquJJsnuKbV2G1DM369cLG0Od+Jwge@mail.gmail.com>
	<877hfyzncy.fsf@matica.localdomain>
	<AANLkTi=iwDFH2RRwJ+NfdCd4YvS3s-ca5ddpSznnv0T9@mail.gmail.com>
	<878w08b08f.fsf@matica.localdomain>
	<20101202175803.884907iax7aj71kc@webmail.rawbw.com>
Message-ID: <87vd3b793n.fsf@matica.localdomain>


Michael> Well, ... depends a bit how one logs in, ... may or may not
Michael> *directly* be a daemon, ... but there would at least be inetd
Michael> or xinetd or init somewhere behind it ... it nothing else.  Has
Michael> to be something that forks/execs that shell or
Michael> login/shell/process.

Right, my working definition of daemonness (daemonicity?) was 1. lives
forever and 2. has no controlling tty.  This process will become Karen's
shell (if she ever logs in on that tty) and then will die when she logs
out, only to be promptly replaced by its next incarnation.

Since everything is indirectly a successor of init, from that
perspective everything would be a daemon :P  Not necessarily wrong, but
has interesting implications.

-- 
Ian Zimmerman <itz at buug.org>
gpg public key: 1024D/C6FF61AD 
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
Ham is for reading, not for eating.


From khogoboom at gmail.com  Mon Dec  6 20:35:27 2010
From: khogoboom at gmail.com (Karen Hogoboom)
Date: Mon, 6 Dec 2010 20:35:27 -0800
Subject: [buug] hello
In-Reply-To: <878w08b08f.fsf@matica.localdomain>
References: <AANLkTimT0m2WWtkquJJsnuKbV2G1DM369cLG0Od+Jwge@mail.gmail.com>
	<877hfyzncy.fsf@matica.localdomain>
	<AANLkTi=iwDFH2RRwJ+NfdCd4YvS3s-ca5ddpSznnv0T9@mail.gmail.com>
	<878w08b08f.fsf@matica.localdomain>
Message-ID: <AANLkTikYSZsHPQbZzWBX5z-UEe78OBzv=hn0c+5XD912@mail.gmail.com>

Thank you all for the nice intro to buug last Thursday.

On Thu, Dec 2, 2010 at 8:36 AM, Ian Zimmerman <itz at buug.org> wrote:

>
> Karen> That is my new project for awhile then.  login [pam] -- I fail.
> Karen> I don't know why there has to be a daemon for login.
>
> Not a daemon.  This is the same process that becomes your shell after
> you log in.
>
>
So paraphrasing Wiki, a daemon is a process whose parent has terminated
(possibly by its own hand) and so is adopted by init, which is PID 1, and
generally runs in background.  Is that right?

When I log in as karenh rather than root, I see that "login [pam] (login)"
is PID 1115 under root, and then -sh is PID 1116 under karenh, so I guess
that login made me a shell.  I also see that after I do startx, the first of
the three windows that twm creates for me has the title login, and the other
two have xterm as their title.

CTRL-middle mouse button in a window gives me VT options, such as display
scrollbar.  Left clicky on upper left corner minimizes the window to a small
icon.

Left clicky on background does give me twm options and allows me to open a
new xterm.


Now I remember what I wanted to ask about the history of X Window.  From a
little bit of reading, it seemed like the concept of server and client were
reversed from how we think of client and server software now.  If I
understand, there are three kinds of X pieces.  X Server, X Window Manager,
X clients.  Imagine we have three computers.  One is in Boston, Mass, and
two are in Berkeley, CA,   It was originally envisioned that the X Server
would run in Berkeley and the X Window Manager would run in Boston?


Karen> -csh -- I fail. Looks like a vararg or parameter or flag, not a
> Karen> process.
>
> I said high level :)  You don't need to understand the flags.  Just what
> it is and why it is running.  This is your shell (which used to be a
> login process).  The leading dash is just a trick to make it know it is
> in fact a login shell, and not just any random interactive shell that
> you started by typing "csh".  But that is a detail that can wait for
> much later.
>
> Karen> /bin/sh /usr/local/bin/startx -- I sort of get this, but am
> Karen> wondering I need to be logged in as root if this computer is its
> Karen> own server, window manager with its own clients.
>
> No, because the X server is setuid root.  setuid is kind of important
> concept, maybe google it.
>

I read about it many years ago.  It is the damage with chmod that my IT guy
at the time would never want me to do.


> hth
> --
> Ian Zimmerman <itz at buug.org>
> gpg public key: 1024D/C6FF61AD
> fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
> Ham is for reading, not for eating.
>



-- 
http://www.linkedin.com/in/karenlhogoboom
http://www.facebook.com/klhogoboom
http://boomtownbits.livejournal.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buug.org/pipermail/buug/attachments/20101206/4e887d4b/attachment.html>

From itz at buug.org  Mon Dec  6 21:20:00 2010
From: itz at buug.org (Ian Zimmerman)
Date: Mon, 06 Dec 2010 21:20:00 -0800
Subject: [buug] hello
In-Reply-To: <AANLkTikYSZsHPQbZzWBX5z-UEe78OBzv=hn0c+5XD912@mail.gmail.com>
	(Karen Hogoboom's message of "Mon, 6 Dec 2010 20:35:27 -0800")
References: <AANLkTimT0m2WWtkquJJsnuKbV2G1DM369cLG0Od+Jwge@mail.gmail.com>
	<877hfyzncy.fsf@matica.localdomain>
	<AANLkTi=iwDFH2RRwJ+NfdCd4YvS3s-ca5ddpSznnv0T9@mail.gmail.com>
	<878w08b08f.fsf@matica.localdomain>
	<AANLkTikYSZsHPQbZzWBX5z-UEe78OBzv=hn0c+5XD912@mail.gmail.com>
Message-ID: <878w02kvlr.fsf@matica.localdomain>


Karen> So paraphrasing Wiki, a daemon is a process whose parent has
Karen> terminated (possibly by its own hand) and so is adopted by init,
Karen> which is PID 1, and generally runs in background. Is that right?

Not quite.  A nondaemon process can very well be orphaned.  The real
essence of being daemon is what I said in the other subthread: not
having a "controlling" terminal.  That being a terminal whose
disconnection (in some fashion, physical or logical) causes the process
to die, and from which it can (if it is in the foreground) receive INT
and QUIT signals.

That last clause also touches on the foreground/background divide.
Technically, only processes with a controlling terminal can be either of
these.  Daemons are in a separate category even farther on the way to
netherworld.

Karen> When I log in as karenh rather than root, I see that "login [pam]
Karen> (login)" is PID 1115 under root, and then -sh is PID 1116 under
Karen> karenh, so I guess that login made me a shell.

Hmm.  You should do a "ps w" in that situation to see who is the shell's
parent.  It is not necessarily the process with the immediately
preceding ID.  I suspect the login process is just waiting for a
password to be typed on another virtual terminal.

Classically, login just *exec*s the shell, it doesn't fork a new
process.  Do you understand the difference?

It is possible that FreeBSD now does things differently.  I'm very much
a Linux guy so I wouldn't know.

Karen> Now I remember what I wanted to ask about the history of X
Karen> Window. From a little bit of reading, it seemed like the concept
Karen> of server and client were reversed from how we think of client
Karen> and server software now. If I understand, there are three kinds
Karen> of X pieces.? X Server, X Window Manager, X clients.  Imagine we
Karen> have three computers. One is in Boston, Mass, and two are in
Karen> Berkeley, CA, It was originally envisioned that the X Server
Karen> would run in Berkeley and the X Window Manager would run in
Karen> Boston?

The window manager is just another client, although one that does things
clients normally don't.  So, if you were working on a machine in Boston
and running client programs on it, the WM would probably be there too.
And yes, this was very much anticipated by the design (although this
particular scenario would be both slow and insecure, unless you go
through a tunnel).

-- 
Ian Zimmerman <itz at buug.org>
gpg public key: 1024D/C6FF61AD 
fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
Ham is for reading, not for eating.


From rick at linuxmafia.com  Mon Dec  6 23:35:36 2010
From: rick at linuxmafia.com (Rick Moen)
Date: Mon, 6 Dec 2010 23:35:36 -0800
Subject: [buug] hello
In-Reply-To: <AANLkTikYSZsHPQbZzWBX5z-UEe78OBzv=hn0c+5XD912@mail.gmail.com>
References: <AANLkTimT0m2WWtkquJJsnuKbV2G1DM369cLG0Od+Jwge@mail.gmail.com>
	<877hfyzncy.fsf@matica.localdomain>
	<AANLkTi=iwDFH2RRwJ+NfdCd4YvS3s-ca5ddpSznnv0T9@mail.gmail.com>
	<878w08b08f.fsf@matica.localdomain>
	<AANLkTikYSZsHPQbZzWBX5z-UEe78OBzv=hn0c+5XD912@mail.gmail.com>
Message-ID: <20101207073536.GW22558@linuxmafia.com>

Quoting Karen Hogoboom (khogoboom at gmail.com):

> From a little bit of reading, it seemed like the concept of server and
> client were reversed from how we think of client and server software
> now.

Not really:  What the X server is serving up to clients is its
network-accessible services in drawing X11 primatives for an output device.
Think of it that way, and you'll find it all makes sense.


> If I understand, there are three kinds of X pieces.  X Server, X Window 
> Manager, X clients.

Sort of.  A window manager actually -=is=- an Xll client, merely one of
a specialised category that handles interactions between other clients
and each other, and between other clients and the X11 server.  At any
given time, your running server can deal with either one or zero running
window manager, i.e., at most one.

You can do an interesting and instructive experiment by configuring your
system to not run X11 by default (not run an X display manager), then
edit ~/.xinitrc to start just one _non-window-manager_ X11 client, e.g.
edit it to say just this one line:

xterm

Save.  Then do 'startx' as usual -- except this time you'll see a
mottled grey X11 display with a single xterm window somewhere on-screen,
where the xterm has _no controls_ on its edges.  You can then experiment
with launching different window managers at the xterm's command prompt,
one at a time, observing how the xterm's controls and decorations change
with each different window manager, along with other associated desktop
widgets coming and going as you start and kill and replace each window
manager.  Like this:

wmaker &
killall wmaker
fvwm &
killall fvwm
twm &
killall twm
icewm &
killall icewm
blackbox &
killall blackbox

And so on.  When you're tired of this experiment, type 'exit' or Ctrl-D
at the xterm's command prompt, and X11 will immediately shut down and
dump you back at the non-graphical console prompt whence you came.




From khogoboom at gmail.com  Tue Dec  7 08:41:51 2010
From: khogoboom at gmail.com (Karen Hogoboom)
Date: Tue, 7 Dec 2010 08:41:51 -0800
Subject: [buug] hello
In-Reply-To: <878w02kvlr.fsf@matica.localdomain>
References: <AANLkTimT0m2WWtkquJJsnuKbV2G1DM369cLG0Od+Jwge@mail.gmail.com>
	<877hfyzncy.fsf@matica.localdomain>
	<AANLkTi=iwDFH2RRwJ+NfdCd4YvS3s-ca5ddpSznnv0T9@mail.gmail.com>
	<878w08b08f.fsf@matica.localdomain>
	<AANLkTikYSZsHPQbZzWBX5z-UEe78OBzv=hn0c+5XD912@mail.gmail.com>
	<878w02kvlr.fsf@matica.localdomain>
Message-ID: <AANLkTimBibc_1BFm8ZGN=bnSQy3scDfCE6YAz-6vm4bJ@mail.gmail.com>

On Mon, Dec 6, 2010 at 9:20 PM, Ian Zimmerman <itz at buug.org> wrote:

...much to think on...I will get back to you...need to find that other
subthread....

Classically, login just *exec*s the shell, it doesn't fork a new
> process.  Do you understand the difference?
>

I think when you fork a process, a copy of the process memory is made and a
new PID is assigned to the new copy, and then it gets to run as its own new
process.

I think when you do an exec in the shell, you are still working within the
same process as the shell.



> It is possible that FreeBSD now does things differently.  I'm very much
> a Linux guy so I wouldn't know.
>

Professor Harvey, from whom I took Operating Systems, said that we would
work on FreeBSD instead of Linux because it was not, not invented here.
Since I was born in Berkeley, CA, I decided I would try to make FreeBSD my
main OS because I was also NNIH.  :-)

...much more to think on and respond to...

--
> Ian Zimmerman <itz at buug.org>
> gpg public key: 1024D/C6FF61AD
> fingerprint: 66DC D68F 5C1B 4D71 2EE5  BD03 8A00 786C C6FF 61AD
> Ham is for reading, not for eating.
>

-- 
http://www.linkedin.com/in/karenlhogoboom
http://www.facebook.com/klhogoboom
http://boomtownbits.livejournal.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buug.org/pipermail/buug/attachments/20101207/8ea00065/attachment.html>

From khogoboom at gmail.com  Tue Dec  7 08:45:33 2010
From: khogoboom at gmail.com (Karen Hogoboom)
Date: Tue, 7 Dec 2010 08:45:33 -0800
Subject: [buug] hello
In-Reply-To: <20101130200621.GJ21203@linuxmafia.com>
References: <AANLkTimT0m2WWtkquJJsnuKbV2G1DM369cLG0Od+Jwge@mail.gmail.com>
	<20101130030512.GX9659@linuxmafia.com>
	<AANLkTimOPtJUQW7PCeO6aYDhJXwBBUQKZFxFBE6cx02O@mail.gmail.com>
	<87lj4ada7k.fsf@matica.localdomain>
	<20101130200621.GJ21203@linuxmafia.com>
Message-ID: <AANLkTin4m40EM_=sF8HkTOfU8jJ0ZC5LaHB+nECbVnfU@mail.gmail.com>

On Tue, Nov 30, 2010 at 12:06 PM, Rick Moen <rick at linuxmafia.com> wrote:

> Quoting Ian Zimmerman (itz at buug.org):
>
> > There is also The Comprehensive List of Window Managers for Unix:
> > http://www.gilesorr.com/wm/table.html
>
> For convenience:  Both pages are always re-findable via the 'Admin'
> category of my Linuxmafia.com Knowledgebase:
>
> http://linuxmafia.com/kb/Admin
>

Thank you!


> _______________________________________________
> Buug mailing list
> Buug at weak.org
> http://www.weak.org/mailman/listinfo/buug
>



-- 
Karen L. Hogoboom

http://www.linkedin.com/in/karenlhogoboom
http://www.facebook.com/klhogoboom
http://boomtownbits.livejournal.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buug.org/pipermail/buug/attachments/20101207/90f69b6f/attachment.html>

From Michael.Paoli at cal.berkeley.edu  Sun Dec 12 11:04:35 2010
From: Michael.Paoli at cal.berkeley.edu (Michael Paoli)
Date: Sun, 12 Dec 2010 11:04:35 -0800
Subject: [buug] nice intro to ...
In-Reply-To: <AANLkTikYSZsHPQbZzWBX5z-UEe78OBzv=hn0c+5XD912@mail.gmail.com>
References: <AANLkTimT0m2WWtkquJJsnuKbV2G1DM369cLG0Od+Jwge@mail.gmail.com>
	<877hfyzncy.fsf@matica.localdomain>
	<AANLkTi=iwDFH2RRwJ+NfdCd4YvS3s-ca5ddpSznnv0T9@mail.gmail.com>
	<878w08b08f.fsf@matica.localdomain>
	<AANLkTikYSZsHPQbZzWBX5z-UEe78OBzv=hn0c+5XD912@mail.gmail.com>
Message-ID: <20101212110435.207234er35b1mneo@webmail.rawbw.com>

> From: "Karen Hogoboom" <khogoboom at gmail.com>
> Subject: Re: [buug] hello
> Date: Mon, 6 Dec 2010 20:35:27 -0800

> Thank you all for the nice intro to buug last Thursday.

Yup, ... good meeting you too.

Perhaps some of us will also see you at the
Berkeley Linux Users Group
http://www.berkeleylug.com/
today.



From cjr at grundrisse.org  Sun Dec 12 19:52:13 2010
From: cjr at grundrisse.org (Claude Rubinson)
Date: Sun, 12 Dec 2010 21:52:13 -0600
Subject: [buug] Best practices for stderr messages?
Message-ID: <20101213035213.GJ24899@wagner>

I'm wondering if anybody might be familiar with a "best practices"
document for writing error messages, specifically for shell scripts
outputting to stderr.

I'm not so interested in recommendations for formatting conventions
(although that would also be welcome) but, more specifically,
recommendations for phrasing, useful/conventional terminology, etc.  I
find myself struggling to balance clarity and brevity and am wondering
if somebody might have already talked about the issue.

In Erik Raymond's /Art of Unix Programming/, he provides a list of
conventional/common flags for shell scripts.  In a sense, I'm
wondering if there might be a similar analogue for error messages.

The program in question is a collection of shell scripts that I'm
writing for social research analysis.  There will be some seasoned
Unix/Linux users in the target audience but many will be Mac or Linux
people unfamiliar with Unix conventions.  I expect that users will
have a range of familiarity with the technique from novice to expert.
So I have a particular interest in my error and warning messages being
technically precise but also straightforward and intelligible, without
being too verbose.  (One thing that I'm doing to help accomplish this
is to provide references to published and unpublished articles that
discuss the issue raised by the warning/error, e.g., (see: Rubinson
2009), which should help a bit.)

Thanks!

Claude


From nick at zork.net  Mon Dec 13 02:26:19 2010
From: nick at zork.net (Nick Moffitt)
Date: Mon, 13 Dec 2010 10:26:19 +0000
Subject: [buug] Best practices for stderr messages?
In-Reply-To: <20101213035213.GJ24899@wagner>
References: <20101213035213.GJ24899@wagner>
Message-ID: <20101213102619.GN9643@zork.net>

Claude Rubinson:
> I'm not so interested in recommendations for formatting conventions
> (although that would also be welcome) but, more specifically,
> recommendations for phrasing, useful/conventional terminology, etc.  I
> find myself struggling to balance clarity and brevity and am wondering
> if somebody might have already talked about the issue.

It depends entirely on what you are using stderr *for*, unfortunately.
So many programs find stderr as a convenient reporting channel that it
can tend to get noisy.  

The big split I've found is basically this:

	1. Program results in files created/modified on filesystem.
	Stdout is used for status information and user prompts, and
	stderr is used for fault reporting.

	2. Program results in data spewed to stdout.  Stderr is used for
	any and all reporting to the user.

Some programs of course allow you to tailor this behavior.  For example,
wget is a bit of a chimera, because it allows you to either make
multiple files on disk or spew data to stdout, so it follows the stderr
usage from #2.  

Personally I've taken to using logging utilities for my stderr spew,
partly because it allows me to use the same code in a python module for
a daemon as for an interactive shell utility.  The result is that my
stderr output for the interactive tools tends to look very syslog-ish,
complete with timestamps, severity levels, and so forth.  I don't see
this as necessarily a bad trend.

-- 
	01234567 <- The amazing* Indent-O-Meter!
        ^
*: Indent-O-Meter may not actually amaze.


From cjr at grundrisse.org  Mon Dec 13 10:46:36 2010
From: cjr at grundrisse.org (Claude Rubinson)
Date: Mon, 13 Dec 2010 12:46:36 -0600
Subject: [buug] Best practices for stderr messages?
In-Reply-To: <20101213102619.GN9643@zork.net>
References: <20101213035213.GJ24899@wagner>
 <20101213102619.GN9643@zork.net>
Message-ID: <20101213184636.GT24899@wagner>

On Mon, Dec 13, 2010 at 10:26:19AM +0000, Nick Moffitt wrote:
> Claude Rubinson:
> > I'm not so interested in recommendations for formatting conventions
> > (although that would also be welcome) but, more specifically,
> > recommendations for phrasing, useful/conventional terminology, etc.  I
> > find myself struggling to balance clarity and brevity and am wondering
> > if somebody might have already talked about the issue.
> 
> It depends entirely on what you are using stderr *for*, unfortunately.
> So many programs find stderr as a convenient reporting channel that it
> can tend to get noisy.  
> 
> The big split I've found is basically this:
> 
> 	1. Program results in files created/modified on filesystem.
> 	Stdout is used for status information and user prompts, and
> 	stderr is used for fault reporting.
> 
> 	2. Program results in data spewed to stdout.  Stderr is used for
> 	any and all reporting to the user.

This is a helpful distinction.  My suite of programs definitely falls
into the latter category: filters reading stdin, outputting to stdout,
and with both fatal errors as well as warnings going to stderr.

It also suggests another way of asking my question: Does anybody have
suggestions of programs that I might emulate; ones that do a
particularly good job at providing useful-yet-manageable stderr
output?

> Personally I've taken to using logging utilities for my stderr spew,

I hadn't considered that; it's an interesting idea that I'll have to
consider.

Thanks,

Claude


From khogoboom at gmail.com  Tue Dec 14 05:42:06 2010
From: khogoboom at gmail.com (Karen Hogoboom)
Date: Tue, 14 Dec 2010 05:42:06 -0800
Subject: [buug] hello
In-Reply-To: <1291760702.3140.0.camel@vulcan>
References: <AANLkTimT0m2WWtkquJJsnuKbV2G1DM369cLG0Od+Jwge@mail.gmail.com>
	<877hfyzncy.fsf@matica.localdomain>
	<1291759722.2678.6.camel@vulcan>
	<AANLkTi=G6=W0drj-BrjcgSLQJQfur4JrQN=bKKRMG48o@mail.gmail.com>
	<1291760702.3140.0.camel@vulcan>
Message-ID: <AANLkTi=NF=8EY+SvV6Y3FQPydu3SDATxkM4q1hFZv1Dw@mail.gmail.com>

On Tue, Dec 7, 2010 at 2:25 PM, PR <oly562 at gmail.com> wrote:

> i believe it was xerox who first developed the mouse and desktop gui.
> shrugs
>

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buug.org/pipermail/buug/attachments/20101214/ca3854d1/attachment.html>

From jim at well.com  Wed Dec 15 08:08:49 2010
From: jim at well.com (jim)
Date: Wed, 15 Dec 2010 08:08:49 -0800
Subject: [buug] BayPIGgies meeting Thursday, December 16, 2010: Plone, Zope,
 Pyramid, Django
Message-ID: <1292429329.1942.35.camel@jim-laptop>



This meeting's talk is 
Plone, Zope, Pyramid, Django  
by Elizabeth Leddy 

   As the first object publishing framework ever, Zope has been 
through several major overhauls and developed a bad reputation 
along the way. 
   The reformulation of pylons and repoze into pyramid presents 
a great opportunity for zope to get back some street cred and 
offer sincere alternatives to front running frameworks like Django. 
   This discussion will cover the current state of zope based 
technologies including repoze/pyramid, grok, bluebream, and plone. 
It will look at the best use cases for each framework, strengths, 
weaknesses, and deal breakers. 
If there is time/interest we will look at the zodb and other core 
zope concepts that you will find in each framework.

   A python developer since the age of 18, I have been developing 
zope and plone applications for over 8 years. I am currently a 
member of the Plone Framework Team and actively develop in multiple 
Python frameworks. 
   I appreciate diversity in frameworks as well as OSS communities, 
so you'll frequently hear me talking about both. 

.........................................

Meetings usually start with a Newbie Nugget, a short discussion of 
an essential Python feature, especially for those new to Python. 
Tonight's Newbie Nugget: none. 


LOCATION 
Symantec Corporation
Symantec Vcafe
350 Ellis Street
Mountain View, CA 94043
http://maps.google.com/maps/ms?oe=utf-8&client=firefox-a&ie=UTF8&fb=1&split=1&gl=us&ei=w6i_Sfr6MZmQsQOzlv0v&hl=en&t=h&msa=0&msid=116202735295394761637.00046550c09ff3d96bff1&ll=37.397693,-122.053707&spn=0.002902,0.004828&z=18

BayPIGgies meeting information is available at 
http://www.baypiggies.net/ 


------------------------ Agenda ------------------------


..... 7:30 PM ...........................
General hubbub, inventory end-of-meeting announcements, 
any first-minute announcements. 


..... 7:35 PM to 7:35 PM ................
Tonight's Newbie Nugget: none. 


..... 7:35 PM to 8:25 PM (or so) ................
The talk: Plone, Zope, Pyramid, Django 


..... 8:25 PM to 8:55 PM (or so) ................
Questions and Answers 


..... 8:55 PM to 9:30 PM (or so) ................
Mapping and Random Access

Mapping is a rapid-fire audience announcement of issues, 
hiring, events, and other topics. 

Random Access follows people immediately to allow follow 
up on the announcements and other interests.




From khogoboom at gmail.com  Fri Dec 24 07:07:02 2010
From: khogoboom at gmail.com (Karen Hogoboom)
Date: Fri, 24 Dec 2010 07:07:02 -0800
Subject: [buug] Best practices for stderr messages?
In-Reply-To: <20101213035213.GJ24899@wagner>
References: <20101213035213.GJ24899@wagner>
Message-ID: <AANLkTi=YS1-1K8apzMr+OAU5eSLATgMP_-XkO6E07_xG@mail.gmail.com>

The program in question is a collection of shell scripts that I'm

> writing for social research analysis.  There will be some seasoned
> Unix/Linux users in the target audience but many will be Mac or Linux
> people unfamiliar with Unix conventions.  I expect that users will
> have a range of familiarity with the technique from novice to expert.
> So I have a particular interest in my error and warning messages being
> technically precise but also straightforward and intelligible, without
> being too verbose.  (One thing that I'm doing to help accomplish this
> is to provide references to published and unpublished articles that
> discuss the issue raised by the warning/error, e.g., (see: Rubinson
> 2009), which should help a bit.)
>

I like the idea of providing the links.  That's a good idea.

I provide different error messages for each error state if I can.

I try to tell the user what they can do to fix the error.  If not, I tell
them which input was not expected.  I tell the user which module it failed
in because I don't assume that they are the one who had the problem.  I.e.,
it could have been me the programmer, or some other programmer down the line
trying to maintain my stuff.  I make the message clear enough for other
programmers to maintain my stuff because I don't assume that whoever paid me
to write the software will necessarily want to be tied to me in perpetuity.
I decide I am a professional software engineer, not a future slimey
consultant.

I think it's better to use more words if it's going to save the user time in
fixing their problem.  I.e., they could spend more time reading the error
message and then know what to do, or they could read a few ambiguous words
and spend the rest of the day Googling.

I take the time to make it concice and clear.

I do not necessarily make the error messages complete sentences unless it
really takes more than one sentence to describe the problem and how to
recover from it.

Karen

http://www.linkedin.com/in/karenlhogoboom
http://www.facebook.com/klhogoboom
http://boomtownbits.livejournal.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://buug.org/pipermail/buug/attachments/20101224/11b01a25/attachment.html>

From george at galis.org  Fri Dec 24 15:33:55 2010
From: george at galis.org (George Georgalis)
Date: Fri, 24 Dec 2010 15:33:55 -0800
Subject: [buug] Best practices for stderr messages?
In-Reply-To: <AANLkTi=YS1-1K8apzMr+OAU5eSLATgMP_-XkO6E07_xG@mail.gmail.com>
References: <20101213035213.GJ24899@wagner>
	<AANLkTi=YS1-1K8apzMr+OAU5eSLATgMP_-XkO6E07_xG@mail.gmail.com>
Message-ID: <AANLkTin6R882OKjAU+xxyMO8mBth-w-1pOHgEuXUR9w4@mail.gmail.com>

On Fri, Dec 24, 2010 at 7:07 AM, Karen Hogoboom <khogoboom at gmail.com> wrote:
....
>> (One thing that I'm doing to help accomplish this
>> is to provide references to published and unpublished articles that
>> discuss the issue raised by the warning/error, e.g., (see: Rubinson
>> 2009), which should help a bit.)
>
> I like the idea of providing the links.? That's a good idea.

Yes, reference the RFC, requirement or whatever justified the test in
the first place. Nothing worse than an archaic error message that
requires issue resolution to identify the problem.

-George