From: Sidney Lambe on
On comp.unix.shell, Jerry Peters <jerry(a)example.invalid> wrote:
> Sidney Lambe <sidneylambe(a)nospam.invalid> wrote:
>> On comp.unix.shell, Sidney Lambe <sidneylambe(a)nospam.invalid>
>> wrote:
>>
>>> On comp.unix.shell, Mart Frauenlob <mart.frauenlob(a)chello.at>
>>> wrote:
>>>
>>>> On 01.02.2010 08:12, Hongyi Zhao wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I want to do the following simple addition operations under
>>>>> bash by using expr:
>>>>>
>>>>> 1- I've two variables, i.e., aa and bb.
>>>>>
>>>>> 2- If the addition of aa + bb is little than 10, it should
>>>>> give me the output with a leading zero like this: 01, 08, 09
>>>>> or so.
>>>>>
>>>>> 3- If the addition of aa + bb is large than 10, it should
>>>>> give me the output without a leading zero.
>>>>>
>>>>> What should I do?
>>>>>
>>>>> Thanks in advance.
>>>>
>>>>
>>>> eris:~# a=3 eris:~# printf "%02d\n" "$a" 03 eris:~# a=33
>>>> eris:~# printf "%02d\n" "$a" 33
>>>>
>>>>
>>>
>>>
>>>
>>> Okay, I think I've got it. But what if a=333?
>>>
>>> Sid
>>>
>>
>> It still works. Baffling. Back to the man page.
>>
>> I could have sworn that 2 limited the output to
>> two columns.
>>
>> Sid
>>
> No, it sets the *minimum* width to 2, the maximum is what is required
> to print the field.
>
> Jerry

Thanks. I'll add that to my notes.

Sid

From: Ivan Shmakov on
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "S" == Seebs <usenet-nospam(a)seebs.net> writes:
>>>>> "IS" == Ivan Shmakov <ivan(a)main.uusia.org> wrote:

IS> The documentation for the GNU project's tools is maintained in the
IS> Texinfo format.

S> Which violates the principle of least surprise to an astonishing
S> extent.

... What really surprises me is the special handling of ! by the
interactive Bash instances. I assume that this feature was here
before Bash got its (or, well, GNU Readline's) history features,
or, in other words, long before I ever learned that there's such
a language as Shell. (Right, there's $ set +H for a cure, but
it's the confusing defaults what I'm concerned with.)

S> The "info" browser remains pathologically hard to use if you happen
S> not to be primarily used to emacs,

S> the HTML forms are annoying at best in a plain text terminal,

I have no trouble switching between Lynx and Less. Are there
specific problems?

S> and they are not where experienced UNIX users look for
S> documentation.

That's the point. Working as an instructor (part-time) in a
local university, I have to deal with inexperienced users more
often than with experienced ones. Moreover, I can't honestly
proclaim myself as an experienced Unix user either, because ever
since my introduction to the Unix-like systems over a decade
ago, I've worked almost exclusively with GNU systems.

S> On paper, it must have sounded great to invent a shiny new
S> documentation format which corrected all sorts of deficiencies.

This particular format was designed, IIUC, in early 1990's, even
before the rise of HTML, and doesn't offer to correct much, if
any, of the deficiences of the latter, or many other formats
developed since.

In fact, I'd say that Texinfo and Info are much inferior to the
modern XML-based formats, such as Docbook. But their wide use
as the standard means for documenting the GNU project give them
the value that the more sophisticated systems for preparing
documentation are lacking.

S> In practice, it means that there's no simple command

Do you mean Shell command specifically here?

S> you can type to get "the complete text of the manual for program X"
S> in a searchable and usable form,

In Emacs, there's M-x info. And with the index at `i', it's
even more searchable than Man pages, plain text or HTML pages.

S> and that if you do the thing that everyone has told you to do every
S> time you have asked a UNIX question in your entire life, you
S> inexplicably get shoddy and half-baked documentation.

S> It really is a very bad decision.

Huh? And where have you been when Texinfo / Info was approved
for GNU?

S> That said, the printf command is pretty decently documented on many
S> systems, and it's nearly self-explanatory, except for the
S> inexplicably stupid behavior of %c.

- --
FSF associate member #7257
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktnY04ACgkQMBO2oCMOM0rPUQCgyyvqsuuZLs//xq4oHhLKUK9j
3/sAoOinZJBghtSieGYLnAZlmiHT+cYB
=a+Yq
-----END PGP SIGNATURE-----
From: Seebs on
On 2010-02-01, Ivan Shmakov <ivan(a)main.uusia.org> wrote:
> ... What really surprises me is the special handling of ! by the
> interactive Bash instances. I assume that this feature was here
> before Bash got its (or, well, GNU Readline's) history features,
> or, in other words, long before I ever learned that there's such
> a language as Shell. (Right, there's $ set +H for a cure, but
> it's the confusing defaults what I'm concerned with.)

It's at least less bad than it used to be; it used to expand !
*EVEN INSIDE SINGLE QUOTES*.

Ugh.

> I have no trouble switching between Lynx and Less. Are there
> specific problems?

The specific problem is that I want something which is actually a working
pager containing the whole text. My usual usage of man pages is to pipe
them through 'col -b' and pop them up in vi. :)

> S> and they are not where experienced UNIX users look for
> S> documentation.

> That's the point. Working as an instructor (part-time) in a
> local university, I have to deal with inexperienced users more
> often than with experienced ones. Moreover, I can't honestly
> proclaim myself as an experienced Unix user either, because ever
> since my introduction to the Unix-like systems over a decade
> ago, I've worked almost exclusively with GNU systems.

Even so, "you should always read the man page, except that some commands
will have either no man page or a willfully crappy one, in which case there's
a totally unrelated command you should try, but for most stuff it won't
have anything" is just plain stupid design.

> S> On paper, it must have sounded great to invent a shiny new
> S> documentation format which corrected all sorts of deficiencies.

> This particular format was designed, IIUC, in early 1990's, even
> before the rise of HTML, and doesn't offer to correct much, if
> any, of the deficiences of the latter, or many other formats
> developed since.

True. But it was intended, reasonably, as an improvement over man pages.
Just one problem: It simply isn't enough of an improvement to justify the
breakage.

> In fact, I'd say that Texinfo and Info are much inferior to the
> modern XML-based formats, such as Docbook. But their wide use
> as the standard means for documenting the GNU project give them
> the value that the more sophisticated systems for preparing
> documentation are lacking.

Yeah, but even BETTER would have been to just WRITE MAN PAGES.

Or, at the very least, have a sane default output from texinfo docs which
rendered to man pages so man would work.

> S> In practice, it means that there's no simple command

> Do you mean Shell command specifically here?

Ayup.

> S> you can type to get "the complete text of the manual for program X"
> S> in a searchable and usable form,

> In Emacs, there's M-x info. And with the index at `i', it's
> even more searchable than Man pages, plain text or HTML pages.

Again, info may be marginally livable if you use emacs for everything and
nothing else for anything.

An index on a whole bunch of separate documents is often less useful than
a single all-in-one searchable text document. The people doing the indexes
may not have categorized something the way I would have; a plain search is
often faster.

> Huh? And where have you been when Texinfo / Info was approved
> for GNU?

I came into the picture late.

But it doesn't matter who was where, or when. What matters is that the
underlying engineering principles which make it a bad idea have been
well understood by engineers since the 70s, and are still true today.

It was a bad call. A reasonable call might have been to develop a distinction
between "basic usage" and "more complete documentation", and keep up-to-date
man pages which cover the use and invocation, then document other things in
info. For instance, you could have an info document describe a language,
but stick with a man page to fully document the compiler -- every option,
every flag, every usage quirk.

Having a command "foo" for which "man foo" does not produce full documentation
of the usage and invocation of the command is a bad choice.

It's like the GNU coding standards. GNU has done some great stuff, but some
of what they've done has been genuinely, fundamentally, awful. They are no
more entitled to the assumption that what they did was right than anyone else
is. They're ordinary humans, with the ordinary run of human frailties, ego
problems, and more. They're as vulnerable to NIH as the SysV and BSD people
ever were, and for the same reason -- they're human.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Maxwell Lol on
Sidney Lambe <sidneylambe(a)nospam.invalid> writes:

> On comp.unix.shell, Bit Twister <BitTwister(a)mouse-potato.com>
> wrote:
>
>> On 1 Feb 2010 09:16:38 +0100, Sidney Lambe wrote:
>>
>>> Okay, I think I've got it. But what if a=333?
>>
>> For crying out loud, you seemed to have proclaimed yourself
>> mister cli and run no gui desktop manager, just enter
>>
>> a=333 printf "%02d\n" "$a"
>>
>> at the command line prompt and see what happens.
>>
>>
>
>
> For crying out loud: If you had read the thread before running
> your mouth, you would have seen that I obviously did just
> that.

You you FIRST asked the question,
and THEN you typed the command that answered your question?

If anyone else did that, you'd flame them.
From: Ivan Shmakov on
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "S" == Seebs <usenet-nospam(a)seebs.net> writes:
>>>>> "IS" == Ivan Shmakov <ivan(a)main.uusia.org> wrote:

[...]

IS> I have no trouble switching between Lynx and Less. Are there
IS> specific problems?

S> The specific problem is that I want something which is actually a
S> working pager containing the whole text. My usual usage of man
S> pages is to pipe them through 'col -b' and pop them up in vi. :)

The same way you could call $ lynx -dump on a URL and have the
output in anything. Sure, it's harder with Info.

Of course, Emacs has a better option, both for Man pages (M-x
man, with working cross-references, etc.) and Web (though I've
forgot how the Emacs package that calls Lynx and beautifies its
output is called.)

S> and they are not where experienced UNIX users look for
S> documentation.

IS> That's the point. Working as an instructor (part-time) in a local
IS> university, I have to deal with inexperienced users more often than
IS> with experienced ones. Moreover, I can't honestly proclaim myself
IS> as an experienced Unix user either, because ever since my
IS> introduction to the Unix-like systems over a decade ago, I've
IS> worked almost exclusively with GNU systems.

S> Even so, "you should always read the man page, except that some
S> commands will have either no man page or a willfully crappy one, in
S> which case there's a totally unrelated command you should try, but
S> for most stuff it won't have anything" is just plain stupid design.

Personally, I'd rather recommend having a hard copy of the
Texinfo manual in question first, to read in one's spare time.

Otherwise, it's rather “check the (info) manual for the package
you're using; check for any manual pages if there's none” in my
version of the universe.

S> On paper, it must have sounded great to invent a shiny new
S> documentation format which corrected all sorts of deficiencies.

IS> This particular format was designed, IIUC, in early 1990's, even
IS> before the rise of HTML, and doesn't offer to correct much, if any,
IS> of the deficiences of the latter, or many other formats developed
IS> since.

S> True. But it was intended, reasonably, as an improvement over man
S> pages. Just one problem: It simply isn't enough of an improvement
S> to justify the breakage.

... Even when it comes to making a hard copy?

[...]

S> you can type to get "the complete text of the manual for program X"
S> in a searchable and usable form,

IS> In Emacs, there's M-x info. And with the index at `i', it's even
IS> more searchable than Man pages, plain text or HTML pages.

S> Again, info may be marginally livable if you use emacs for
S> everything and nothing else for anything.

Well, let me think... I use Emacs when it's justified to “boot”
one on a host. I also use Vim and, occasionally, Ed. Surely, I
use Awk, Tcl and Sed, both from Shell and from Emacs. Does it
count as “nothing else for anything”?

S> An index on a whole bunch of separate documents is often less useful
S> than a single all-in-one searchable text document. The people doing
S> the indexes may not have categorized something the way I would have;
S> a plain search is often faster.

The index, as included into almost every Info document, allows
for a quick access to the documentation for the particular
system or language functions, commands, etc. Instead of having
a Man section to specify a “namespace”, one specifies the
namespace to search in by choosing a particular Info document.

E. g., i printf RET shows the documentation for:

* when one's at (coreutils), it's the printf command;

* (libc) — the same gives the documentation for the C function;

* (gawk) — likewise, but for the GNU Awk statement (though it
doesn't work here; probably the source for the manual misses
an @findex command?);

* (octave) — likewise, but for the Octave function;

* (slib) — likewise, but for the Scheme (SLIB) function.

And now, I'm not completely sure that $ man would allow me to
distinguish at least three different printf functions in its 3rd
section.

IS> Huh? And where have you been when Texinfo / Info was approved for
IS> GNU?

S> I came into the picture late.

Does it mean that Info already existed when you were introduced
to Unix or GNU?

[...]

S> It was a bad call. A reasonable call might have been to develop a
S> distinction between "basic usage" and "more complete documentation",
S> and keep up-to-date man pages which cover the use and invocation,
S> then document other things in info. For instance, you could have an
S> info document describe a language, but stick with a man page to
S> fully document the compiler -- every option, every flag, every usage
S> quirk.

S> Having a command "foo" for which "man foo" does not produce full
S> documentation of the usage and invocation of the command is a bad
S> choice.

Why? Having $ foo --help for basic usage seems to me quite
enough. Therefore, I'd better drop the Man pages entirely for
the sake of simplicity. (The only of my packages that includes
Man pages does this because I had no time to prepare a proper
manual.)

S> It's like the GNU coding standards.

What I like of the GNU coding standards is that they're a
well-documented practice. Sometimes, I advice people to follow
the GNU standards just because “sure, you could invent your own
standards, but why bother? and you're much likely to forget what
you've invented by the time the work is done, anyway!”

S> GNU has done some great stuff, but some of what they've done has
S> been genuinely, fundamentally, awful. They are no more entitled to
S> the assumption that what they did was right than anyone else is.

Still, I was, and continue to be, very impressed by the sheer
volume of work done by the GNU folks. And I owe them much,
because I wouldn't have been a 1% of the programmer I'm now
without the GNU project and, specifically, its documentation.

And, at times, an inferior, but well-documented practice is
better than a superior, but poorly-documented one.

S> They're ordinary humans, with the ordinary run of human frailties,
S> ego problems, and more. They're as vulnerable to NIH as the SysV
S> and BSD people ever were, and for the same reason -- they're human.

- --
FSF associate member #7257
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAktnqCQACgkQMBO2oCMOM0rb8QCg5Zup60f+D/UUFH0DVxld1C2A
GAsAn0noGXqj0I6zFsejhyRRQog/iPSA
=I2hC
-----END PGP SIGNATURE-----