From: Sidney Lambe on 1 Feb 2010 18:17 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 1 Feb 2010 18:27 -----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 1 Feb 2010 18:43 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 1 Feb 2010 20:05 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 1 Feb 2010 23:20 -----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-----
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: Delete Chinese characters from the filenames. Next: Remove certain characters in a filename |