Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Juergen" == Juergen A Erhard <jae@laden.ilk.de> writes:

Juergen> gpg

Juergen> `hangs'. It seems it wants some input (^D
Juergen> terminates). Why does it do that? Why not just give
Juergen> some short help (less than a typical screenful), and
Juergen> terminate?

'gpg' is a filter like 'cat'. Please don't even _think_ about asking
to have that changed. Nobody in their right mind wants to go back to
the lame and maddening ways of various PGP versions in this respect.

Juergen> + Couldn't some of the commands/options be a little
Juergen> shorter? Why is --list-ownertrust not simply
Juergen> --list-trust?

Are you using ~/.gnupg/options? There are also a myriad of other ways
to save typing, particularly for an Emacs user like you. :-) What
about calculated or computed trust?

jam

-----BEGIN PGP SIGNATURE-----
Version: GNUPG v0.4.2
Comment: For info finger gcrypt@ftp.guug.de

iEYEARECAAYFAjYwtZoACgkQUEvv1b/iXy/E4wCfe0xVhlVho9IQMLaa0QnZBVLz
9b8AoJDJDzcO9bXELWrfJO5CM3EYK6FU
=BajN
-----END PGP SIGNATURE-----

"Juergen A. Erhard" <jae@laden.ilk.de> writes:

> no explanation on why a simple
>
> gpg
>
> `hangs'. It seems it wants some input (^D terminates). Why does
> it do that? Why not just give some short help (less than a

Because it is a Unix program and all Unix program have this good
behaviour.

> + Couldn't some of the commands/options be a little shorter? Why is
> --list-ownertrust not simply --list-trust?

Because you should never need it expect in shell scripts.

> + Where's the argument parsing coming from?[1] Standard GNU
> getopt-long does not need the full option, just enough so it is
> uniquely identified. Whereas the current parser needs the *full*
> option (--list-secret-keys is nice and long, --list-sec would be

From WkLib and it is really nice to combine the help with the
commands; there are a lot of tools where the help and the implemneted
commands do not match. I should give it some work.

> [1] arparse.c mentions WkLib... I didn't check whether WkLib is
> mentioned anywhere else in the sources, but I'm sure I haven't seen it
> before. What *Wk*Lib stands for is anyone's guess ;-)

It is a very old function collection which enabled me to write and
port programs to DOS, Windoze, Unix, NT, VMS.


Werner

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "jam" == John A Martin <jam@jamux.com> writes:
>>>>> "Juergen" == Juergen A Erhard <jae@laden.ilk.de> writes:

Juergen> gpg

Juergen> `hangs'. It seems it wants some input (^D
Juergen> terminates). Why does it do that? Why not just give
Juergen> some short help (less than a typical screenful), and
Juergen> terminate?

jam> 'gpg' is a filter like 'cat'. Please don't even _think_
jam> about asking to have that changed. Nobody in their right
jam> mind wants to go back to the lame and maddening ways of
jam> various PGP versions in this respect.

Not only am I thinking about asking, I'm actually asking... and I
don't mean to go `go back to the lame and maddening ways' of PGP.

The problem with the current behavior is that it is neither documented
nor obvious. *What* does this filter do?

What I'd like to see: just `gpg' simply returns (maybe giving some
comment about using --help or something).

A filter function (of whatever kind) could be done like gzip does with
`-c'.

[SNIP]

jam> Are you using ~/.gnupg/options? There are also a myriad of
jam> other ways to save typing, particularly for an Emacs user
jam> like you. :-) What about calculated or computed trust?

I'm not using gpg from Emacs yet... I'm doing shell stuff in an xterm,
and haven't installed mailcrypt with gpg support yet.

Probably need to write a little compctl thingie for zsh...

Bye, J

- --
Jürgen A. Erhard eMail: jae@laden.ilk.de phone: (GERMANY) 0721 27326
MARS: http://members.tripod.com/~Juergen_Erhard/mars_index.html
Free Software Union (http://www.fslu.org)
pros do it for money -- amateurs out of love.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQEVAwUBNkORRwIG66LugGzRAQH0UAgAw19LCb2VE30jVD0iOQQR3uW+LRT0nHg9
ZEPwYzF3RlXszc03q94i2Abk5nmOX4furOH1PjdDiKjJo0CrELLcknsLTFHL+hRD
o8baqOenLXlWI/6SoK6Eq2gu0U3mWekQbUFAEZ7hRbPtCh3CiWD83D0BU6TJP7x8
Wj2tuUURnTuAT3cvhVEF5j0C3OPyVKmyw/PYY3w6C+Onaa9WXdLyZJSLcoaLkGag
OQjIhfU0mwAexMImNl5HJk1CjgWegmJmnL+oVxLAo3yNTaFtjctEBVT0NGBHwTaa
IqOFiohZ9dQyigr0jUscxXG/Niz+hWWQHq5ARs3+pm9gX6bt10sV1A==p8Am
-----END PGP SIGNATURE-----

> Not only am I thinking about asking, I'm actually asking... and I
> don't mean to go `go back to the lame and maddening ways' of PGP.
>
> The problem with the current behavior is that it is neither documented
> nor obvious. *What* does this filter do?

The filter decrypts files, I believe. To you can put 'gpg < cryptfile'
and it will decrypt for you. IMO, I think this is good unix behavior. Gpg
doesn't need an interactive menu or anything, its intended to be an
encryption 'engine`, and a nice gnome ui can be written on top of it. It
is a possibility to make something like --help the default when 'gpg' is
run by itself, and make it a filter with an option, but I don't if that
behavior would be better than the current one. Its pretty standard for
some unix programs to wait for standard input, and it doesn't take long to
try the standard --help option, or man gpg to figure out what is going on.

>>>>> "Juergen" == Juergen A Erhard "Re: UI"
>>>>> Sat, 7 Nov 1998 01:16:09 +0100 (CET)

Juergen> The problem with the current behavior is that it is
Juergen> neither documented nor obvious. *What* does this filter
Juergen> do?

$ echo "Hello World" | gpg -er jam | gpg

You need a passphrase to unlock the secret key for
user: "John A. Martin <jam@acm.org>"
(1024-bit ELG-E key, ID 4FC125AD, created 1998-09-19)

Hello World
$ cat .gnupg/options
no-greeting
$

HTH

jam

On Fri, 6 Nov 1998, Kirk Fort wrote:

> > The problem with the current behavior is that it is neither documented
> > nor obvious. *What* does this filter do?
>
> The filter decrypts files, I believe. To you can put 'gpg < cryptfile'
> and it will decrypt for you. IMO, I think this is good unix behavior.

If you don't mind, I'd like to recommend that when discovering new
programs the first thing you do ought not be `$ command`; rather it
should be `$ man command`. Life is far easier that way and someone did go
to all the hard work of making that page for you to read.

C=)

--------------------------------------------------------------------------
Heuer's Law: Any feature is a bug unless it can be turned off.
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// pager.818.698.2306
TechnoCage Inc. ///| gpg: aiiieeeeeee!!!
--------------------------------------------------------------------------
Early bird gets the worm, but the second mouse gets the cheese.

On Mon, 9 Nov 1998, Holger Schurig wrote:

> However, we can make them much more human-friendly if we look if stdin
> is a TTY and emit a nice message. If the program is used as a filter,
> then stdin is not bound to a TTY. The case that someone types in text
> directly into GnuPG is very, very rare.

I would disagree with this very strongly. I often cut and paste from my
mailreader into an xterm. Despite being able to use the export and filter
commands in pine, I still find this to be the easiest way to do quick gpg
work.

> For example, if you confuse "mailstats" (from sendmail) with "mailstat"
> (from procmail) and type as a command, the following will happen:
>
> $ mailstat
> Most people don't type their own logfiles; but, what do I care?
> $
>
> However, "cat logfile | mailstat" or "mailstat <logfile" or whatever
> works as expected. So we have both: script-friendlyness and
> human-friendlyness.

I'm all for a simple message a-la mailstat. It makes no difference to me
and maintains 'good unix behavior'.

C=)

P.S. I'm curious werner, how many patches do you get for problems vs.
requests to just fix it for us?

--------------------------------------------------------------------------
Heuer's Law: Any feature is a bug unless it can be turned off.
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// pager.818.698.2306
TechnoCage Inc. ///| gpg: aiiieeeeeee!!!
--------------------------------------------------------------------------
Early bird gets the worm, but the second mouse gets the cheese.

>The filter decrypts files, I believe. To you can put 'gpg < cryptfile'
>and it will decrypt for you. IMO, I think this is good unix behavior.

I agree that filters are a VERY good unix behavior, they're very script
friendly.

However, we can make them much more human-friendly if we look if stdin
is a TTY and emit a nice message. If the program is used as a filter,
then stdin is not bound to a TTY. The case that someone types in text
directly into GnuPG is very, very rare.


For example, if you confuse "mailstats" (from sendmail) with "mailstat"
(from procmail) and type as a command, the following will happen:

$ mailstat
Most people don't type their own logfiles; but, what do I care?
$

However, "cat logfile | mailstat" or "mailstat <logfile" or whatever
works as expected. So we have both: script-friendlyness and
human-friendlyness.


-----------------------------+---------------------------------
Holger Schurig | OM Standard Linux Server:
Operation Mobilisation e.V. | http://it-support.om.org/linux
Postfach 1561 |
D-74821 Mosbach | Tel: +49-6261-947-140

On Mon, 9 Nov 1998, Holger Schurig wrote:
> However, we can make them much more human-friendly if we look if stdin
> is a TTY and emit a nice message. If the program is used as a filter,
> then stdin is not bound to a TTY. The case that someone types in text
> directly into GnuPG is very, very rare.

Strongly disagree. This prevents me from cutting and pasting text to GPG
in an xterm, telnet window, or on the Linux console, which I do with
startling regularity. ;-)

--
Edward S. Marshall <emarshal@logic.net> /> Who would have thought that we -o)
http://www.logic.net/~emarshal/ // would be freed from the Gates of /\\
Linux Weenie, Open-Source Advocate </ hell by a penguin named "Tux"? _\_v

Linux labyrinth 2.1.125 #9 SMP Sat Oct 17 14:46:24 CDT 1998 i586 unknown
7:50pm up 10 days, 19:28, 4 users, load average: 0.00, 0.00, 0.00

Edward S. Marshall writes:
On Mon, 9 Nov 1998, Holger Schurig wrote:
> However, we can make them much more human-friendly if we look if stdin
> is a TTY and emit a nice message. If the program is used as a filter,
> then stdin is not bound to a TTY. The case that someone types in text
> directly into GnuPG is very, very rare.
Strongly disagree. This prevents me from cutting and pasting text to GPG
in an xterm, telnet window, or on the Linux console, which I do with
startling regularity. ;-)

How about running it as "gpg - "?

rone
--
Ron Echeverri Numerical Aerospace Simulation Facility
DSS/Usenet Administrator NASA Ames Research Center
Internet Sysop Mountain View, CA
<rone@nas.nasa.gov> x42771

"Caskey L. Dickson" <caskey@technocage.com> writes:

> I'm all for a simple message a-la mailstat. It makes no difference to me
> and maintains 'good unix behavior'.

Okay, I'll add such an advisory note (to stderr or to tty?) in case
stdin AND stdout is a tty - this is more friendy to the Unix newbie.

> P.S. I'm curious werner, how many patches do you get for problems vs.
> requests to just fix it for us?

I hope the low frequency of patches is mostly due to my restrictive
handling of patches (due to the FSF requirements) :-)
But small patches are always okay (and large patches might help me to
solve a problem by looking at them).


Werner

On Tue, 10 Nov 1998 16:44:56 -0100, "Holger Schurig" wrote:
>>I hope the low frequency of patches is mostly due to my restrictive
>>handling of patches (due to the FSF requirements) :-)
>
>I once send something in --- to start, I send a little documentation
>update. Werner immediately said back "No, you have to sign something,
>otherwise I can't accept stuff from you" (which is PERFECTLY ok, I
>don't want to ... hmmm, in German I would say that "dass ich Werner
>nicht an den Karren pinkeln wuerde" but I guess that an english
>translation totally looses the meaning :-)
>
>
>However, I tried to get some answer from FSF.ORG, from "info
>standards" and also from Werner WHAT to actually sign, but never really
>with any usable response. "info standards" for example just says:

The procedure is described at http://egcs.cygnus.com/contribute.html.
Basically you have to sign a copyright assignment form, which is right
there, and mail it to the FSF. Which form you fill out depends on how
much you've contributed and whether you plan on doing so again in the
future. If you are employed to write programs, you may have to get
another form signed by your boss.

fsf.org is really bad about updating their website, which is why this
is over at Cygnus.

zw

>I hope the low frequency of patches is mostly due to my restrictive
>handling of patches (due to the FSF requirements) :-)

I once send something in --- to start, I send a little documentation
update. Werner immediately said back "No, you have to sign something,
otherwise I can't accept stuff from you" (which is PERFECTLY ok, I
don't want to ... hmmm, in German I would say that "dass ich Werner
nicht an den Karren pinkeln wuerde" but I guess that an english
translation totally looses the meaning :-)


However, I tried to get some answer from FSF.ORG, from "info
standards" and also from Werner WHAT to actually sign, but never really
with any usable response. "info standards" for example just says:

-----------------------------------------
If someone else sends you a piece of code to add to the program you
are working on, we need legal papers to use it--the same sort of legal
papers we will need to get from you. *Each* significant contributor to
a program must sign some sort of legal papers in order for us to have
clear title to the program. The main author alone is not enough.

So, before adding in any contributions from other people, tell us so
we can arrange to get the papers. Then wait until we tell you that we
have received the signed papers, before you actually use the
contribution.
-----------------------------------------

However, it says not WHAT channel to use to "tell them" (e-mail, fax,
phone, letter) nor does the www.fsf.org website. So it's still a big
obscurity to me and I won't send in any patches anymore. For exampl,e
it would have been totally easy for me to make a patch (or using CVS
if that is ok) for the GDBM-not-installed problem. But because no one
so far could tell me what to sign I could not check and sign anything,
so Werner can't accept anything but "unsignifant" from me so the world
has to life without my contributions.

Hmm, maybe that's better for the world anyway :-)


-----------------------------+---------------------------------
Holger Schurig | OM Standard Linux Server:
Operation Mobilisation e.V. | http://it-support.om.org/linux
Postfach 1561 |
D-74821 Mosbach | Tel: +49-6261-947-140

> >I hope the low frequency of patches is mostly due to my restrictive
> >handling of patches (due to the FSF requirements) :-)
>
> I once send something in --- to start, I send a little documentation
> update. Werner immediately said back "No, you have to sign something,
> otherwise I can't accept stuff from you" (which is PERFECTLY ok, I
> don't want to ... hmmm, in German I would say that "dass ich Werner
> nicht an den Karren pinkeln wuerde" but I guess that an english
> translation totally looses the meaning :-)
>
>
> However, I tried to get some answer from FSF.ORG, from "info
> standards" and also from Werner WHAT to actually sign, but never really
> with any usable response. "info standards" for example just says:
>
> -----------------------------------------
> If someone else sends you a piece of code to add to the program you
> are working on, we need legal papers to use it--the same sort of legal
> papers we will need to get from you. *Each* significant contributor to
> a program must sign some sort of legal papers in order for us to have
> clear title to the program. The main author alone is not enough.

The way I read this is that Werner had to sign some legal paper(s) to
certify that the code he was writing would belong to the FSF so that
they could hold the copyright and issue it under the GPL. (Is that
right, Werner?) So if someone else makes a *significant* contribution
the FSF need the same papers signed by them because if they didn't
that individual could claim standard legal copyright later and cause
a lot of problems. I would not expect simple bug-fixes like the GDBM
problemette to fall into the category of a "significant contribution".
However, a new mode of operation or command would.

> So, before adding in any contributions from other people, tell us so
> we can arrange to get the papers. Then wait until we tell you that we
> have received the signed papers, before you actually use the
> contribution.

This is an instruction to *Werner* not to incorporate any "significant
contribution" until the necessary documents have been signed. *He*
has to tell the FSF, who will contact the contributor, who will sign
the papers and return them to the FSF, who will tell Werner that he can
go ahead.

> -----------------------------------------
>
> However, it says not WHAT channel to use to "tell them" (e-mail, fax,
> phone, letter) nor does the www.fsf.org website. So it's still a big
> obscurity to me and I won't send in any patches anymore.

But if I'm right (very big if!) we can send things to Werner and he
has to decide if they are "significant" - and hopefully he has some
guidelines from the FSF.

> For exampl,e
> it would have been totally easy for me to make a patch (or using CVS
> if that is ok) for the GDBM-not-installed problem. But because no one
> so far could tell me what to sign I could not check and sign anything,
> so Werner can't accept anything but "unsignifant" from me so the world
> has to life without my contributions.
>
> Hmm, maybe that's better for the world anyway :-)

David Pick <D.M.Pick@qmw.ac.uk> writes:

> This is an instruction to *Werner* not to incorporate any "significant
> contribution" until the necessary documents have been signed. *He*
> has to tell the FSF, who will contact the contributor, who will sign
> the papers and return them to the FSF, who will tell Werner that he can

Anyway, I do this as soon as you promise to sign a disclaimer :-)

> > However, it says not WHAT channel to use to "tell them" (e-mail, fax,
> > phone, letter) nor does the www.fsf.org website. So it's still a big

Letter - and it takes a few *weeks*.

> But if I'm right (very big if!) we can send things to Werner and he
> has to decide if they are "significant" - and hopefully he has some
> guidelines from the FSF.

About 10 lines or any other trivial patch are always okay - I might
consider a patch as a bug report ;-)


Werner

>>>>> "Caskey" == Caskey L Dickson <caskey@technocage.com> writes:

Caskey> On Fri, 6 Nov 1998, Kirk Fort wrote:
>> > The problem with the current behavior is that it is neither documented
>> > nor obvious. *What* does this filter do?
>>
>> The filter decrypts files, I believe. To you can put 'gpg < cryptfile'
>> and it will decrypt for you. IMO, I think this is good unix behavior.

Caskey> If you don't mind, I'd like to recommend that when discovering new
Caskey> programs the first thing you do ought not be `$ command`; rather it
Caskey> should be `$ man command`. Life is far easier that way and someone did go
Caskey> to all the hard work of making that page for you to read.

Thanks for your patronizing words... not!

Carefully reading the manpage (the SYNOPSIS anyway) reveals that

gpg

is impossible.

But it ain't. Typing away merrily after saying `gpg', can result in
this:

gpg: no valid RFC1991 or OpenPGP data found.

or this

gpg: [don't know]: invalid packet (ctb=64)

(which followed directly after `ddddddddddddd', 13 `d's I typed).

Very intuitive. Very helpful.

Let me compare this to gzip again. If you say `gzip', it assumes you
want to compress, but it does not do so, because stdout is bound to a
tty. Add a --force to the gzip call, and it compresses. Which
produces garbage on the terminal.

Anyway,

Bye, J

--
Jürgen A. Erhard eMail: jae@laden.ilk.de phone: (GERMANY) 0721 27326
MARS: http://members.tripod.com/~Juergen_Erhard/mars_index.html
"Outside of a dog, a man's best friend is a book;
inside of a dog, it's very dark." -- Groucho Marx