Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #274923 > unrolled thread

Using terminal commands - corner cases

Back to article view | Back to linux.debian.user

Contents

  Using terminal commands - corner cases Richard Owlett <rowlett@access.net> - 2024-11-27 12:40 +0100
    Re: Using terminal commands - corner cases <tomas@tuxteam.de> - 2024-11-27 13:00 +0100
      Re: Using terminal commands - corner cases Richard Owlett <rowlett@access.net> - 2024-11-27 14:40 +0100
        Re: Using terminal commands - corner cases <tomas@tuxteam.de> - 2024-11-27 14:40 +0100
          Re: Using terminal commands - corner cases Richard Owlett <rowlett@access.net> - 2024-11-27 15:50 +0100
          Re: Using terminal commands - corner cases Joe <joe@jretrading.com> - 2024-11-27 15:50 +0100
        Re: Using terminal commands - corner cases Eric S Fraga <e.fraga@ucl.ac.uk> - 2024-11-27 15:20 +0100
          Re: Using terminal commands - corner cases <tomas@tuxteam.de> - 2024-11-27 15:30 +0100
            help, man, etc. (was Re: Using terminal commands - corner cases) The Wanderer <wanderer@fastmail.fm> - 2024-11-27 16:50 +0100
              Re: help, man, etc. (was Re: Using terminal commands - corner cases) Greg Wooledge <greg@wooledge.org> - 2024-11-27 17:10 +0100
                Re: help, man, etc. (was Re: Using terminal commands - corner cases) <tomas@tuxteam.de> - 2024-11-27 18:10 +0100
              Re: help, man, etc. (was Re: Using terminal commands - corner cases) <tomas@tuxteam.de> - 2024-11-27 18:00 +0100
                Re: help, man, etc. (was Re: Using terminal commands - corner cases) The Wanderer <wanderer@fastmail.fm> - 2024-11-27 18:30 +0100
                  Re: help, man, etc. (was Re: Using terminal commands - corner cases) <tomas@tuxteam.de> - 2024-11-27 18:50 +0100
                Re: help, man, etc. (was: Re: Using terminal commands - corner cases) Max Nikulin <manikulin@gmail.com> - 2024-11-28 03:40 +0100
                  Re: help, man, etc. (was: Re: Using terminal commands - corner cases) <tomas@tuxteam.de> - 2024-11-28 06:40 +0100
          Re: Using terminal commands - corner cases Yassine Chaouche <a.chaouche@algerian-radio.dz> - 2024-11-27 16:40 +0100
          Re: Using terminal commands - corner cases Chris Green <cl@isbd.net> - 2024-11-27 17:20 +0100
      Re: Using terminal commands - corner cases Greg Wooledge <greg@wooledge.org> - 2024-11-27 15:50 +0100
    Re: Using terminal commands - corner cases David Wright <deblis@lionunicorn.co.uk> - 2024-11-28 05:20 +0100
      Re: Using terminal commands - corner cases Richard Owlett <rowlett@access.net> - 2024-11-28 09:40 +0100
      Re: Using terminal commands - corner cases Max Nikulin <manikulin@gmail.com> - 2024-11-28 16:00 +0100
        Re: Using terminal commands - corner cases Richard Owlett <rowlett@access.net> - 2024-11-28 16:20 +0100
          Re: Using terminal commands - corner cases Erwan David <erwan@rail.eu.org> - 2024-11-28 16:20 +0100
        Re: Using terminal commands - corner cases David Wright <deblis@lionunicorn.co.uk> - 2024-11-29 19:40 +0100
          Re: Using terminal commands - corner cases Max Nikulin <manikulin@gmail.com> - 2024-11-30 16:20 +0100
            Re: Using terminal commands - corner cases David Wright <deblis@lionunicorn.co.uk> - 2024-12-02 04:00 +0100
              Re: Using terminal commands - corner cases debian-user@howorth.org.uk - 2024-12-02 13:00 +0100
    Re: Using terminal commands - corner cases Michael Paoli <michael.paoli@berkeley.edu> - 2024-12-02 10:20 +0100

Page 1 of 2  [1] 2  Next page →

#274923 — Using terminal commands - corner cases

I've used terminal commands for so many decades I don't know where to 
look up fine details of a specific commands.

I just tried to use the cd command with a target directory having spaces 
in it's name. Of course the system responded
          > bash: cd: too many arguments

DuckDuckGo led to [ 
https://bash.cyberciti.biz/guide/Cd_command#Dealing_with_directories_with_white_space_in_their_names 
].

Problem solved. But is there somewhere to go directly without a web search?

TIA

[toc] | [next] | [standalone]

#274924

[Multipart message — attachments visible in raw view] — view raw

On Wed, Nov 27, 2024 at 05:38:30AM -0600, Richard Owlett wrote:
> I've used terminal commands for so many decades I don't know where to look
> up fine details of a specific commands.
> 
> I just tried to use the cd command with a target directory having spaces in
> it's name. Of course the system responded
>          > bash: cd: too many arguments
> 
> DuckDuckGo led to [ https://bash.cyberciti.biz/guide/Cd_command#Dealing_with_directories_with_white_space_in_their_names
> ].
> 
> Problem solved. But is there somewhere to go directly without a web search?

First: cd is not a command, it is a shell builtin
(this is subtle, but important).

Second: even if cd were a "command", the splitting
of args at whitespace (among *a lot* of other things)
is done by the shell before the command has even a
chance at it.

So for both reasons, it's not "cd" what you are looking
at, but your shell.

You could do worse than having a look at the Bash Guide,
co-maintained by one of our regulars here. For your case,
the first chapter [1] seems relevant.

Cheers

[1] https://mywiki.wooledge.org/BashGuide/CommandsAndArguments
-- 
t

[toc] | [prev] | [next] | [standalone]

#274925

On 11/27/24 5:55 AM, tomas@tuxteam.de wrote:
> On Wed, Nov 27, 2024 at 05:38:30AM -0600, Richard Owlett wrote:
>> I've used terminal commands for so many decades I don't know where to look
>> up fine details of a specific commands.
>>
>> I just tried to use the cd command with a target directory having spaces in
>> it's name. Of course the system responded
>>           > bash: cd: too many arguments
>>
>> DuckDuckGo led to [ https://bash.cyberciti.biz/guide/Cd_command#Dealing_with_directories_with_white_space_in_their_names
>> ].
>>
>> Problem solved. But is there somewhere to go directly without a web search?
> 
> First: cd is not a command, it is a shell builtin
> (this is subtle, but important).
> 
> Second: even if cd were a "command", the splitting
> of args at whitespace (among *a lot* of other things)
> is done by the shell before the command has even a
> chance at it.
> 
> So for both reasons, it's not "cd" what you are looking
> at, but your shell.
> 
> You could do worse than having a look at the Bash Guide,
> co-maintained by one of our regulars here. For your case,
> the first chapter [1] seems relevant.
> 
> Cheers
> 
> [1] https://mywiki.wooledge.org/BashGuide/CommandsAndArguments
> 

Thank you. I've seen his site before. I just created a bookmark folder 
for "Debian Wikis". The first occupant is https://mywiki.wooledge.org .

I've been a computer *user* for six of my eight decades.
My only formal background was a one semester intro to programming course 
as a freshman E.E. student.
Keep running into things I never knew or had long forgotten ;/
[Only been around Linux since Stretch]

[toc] | [prev] | [next] | [standalone]

#274926

[Multipart message — attachments visible in raw view] — view raw

On Wed, Nov 27, 2024 at 07:30:17AM -0600, Richard Owlett wrote:

[...]

> Thank you. I've seen his site before. I just created a bookmark folder for
> "Debian Wikis". The first occupant is https://mywiki.wooledge.org .

Greg's wiki is a jewel. I thank *him* for it.

> I've been a computer *user* for six of my eight decades.
> My only formal background was a one semester intro to programming course as
> a freshman E.E. student.

[...]

Now what programming language was this?

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#274930

On 11/27/24 7:36 AM, tomas@tuxteam.de wrote:
> On Wed, Nov 27, 2024 at 07:30:17AM -0600, Richard Owlett wrote:
> 
> [...]
> 
>> Thank you. I've seen his site before. I just created a bookmark folder for
>> "Debian Wikis". The first occupant is https://mywiki.wooledge.org .
> 
> Greg's wiki is a jewel. I thank *him* for it.
> 
>> I've been a computer *user* for six of my eight decades.
>> My only formal background was a one semester intro to programming course as
>> a freshman E.E. student.
> 
> [...]
> 
> Now what programming language was this?

CORC/CUPL
https://en.wikipedia.org/wiki/Cornell_University_Programming_Language

Dartmouth's BASIC was more popular. But we had better football ;/


> 
> Cheers
> 

[toc] | [prev] | [next] | [standalone]

#274931

On Wed, 27 Nov 2024 14:36:44 +0100
<tomas@tuxteam.de> wrote:

> On Wed, Nov 27, 2024 at 07:30:17AM -0600, Richard Owlett wrote:
> 
> [...]
> 
> > Thank you. I've seen his site before. I just created a bookmark
> > folder for "Debian Wikis". The first occupant
> > is https://mywiki.wooledge.org .  
> 
> Greg's wiki is a jewel. I thank *him* for it.
> 
> > I've been a computer *user* for six of my eight decades.
> > My only formal background was a one semester intro to programming
> > course as a freshman E.E. student.  
> 
> [...]
> 
> Now what programming language was this?
> 

I would guess most of us in engineering started with some variant of
Fortran. Mine was on an ICL1907 mainframe, which I never saw. IBM 80
column card punches...

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#274927

And, just for the record, should you want to find out more about
commands on Linux without leaving your system (i.e. without any
interaction with the Internet at all), the man command is available to
present the manual pages (dates back to when there was an actual manual
in early unix days) for individual commands, e.g.

man bash

which will describe in quite some detail how to use the shell and

man -k somekeyword

will allow to search man pages.  

bash itself also has a help system: type "help" :-)

-- 
Eric S Fraga via gnus (Emacs 31.0.50 2024-08-16) on Debian 12.6

[toc] | [prev] | [next] | [standalone]

#274928

[Multipart message — attachments visible in raw view] — view raw

On Wed, Nov 27, 2024 at 02:18:02PM +0000, Eric S Fraga wrote:
> And, just for the record, should you want to find out more about
> commands on Linux without leaving your system (i.e. without any
> interaction with the Internet at all), the man command is available to
> present the manual pages (dates back to when there was an actual manual
> in early unix days) for individual commands, e.g.
> 
> man bash
> 
> which will describe in quite some detail how to use the shell and
> 
> man -k somekeyword
> 
> will allow to search man pages.  
> 
> bash itself also has a help system: type "help" :-)

Good points -- as a tip, turn things around: first try "help foo",
then "man foo" whenever you don't know whether what you have is
a builtin or a command.

And yes, it's a pity there is no common frontend for both.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#274933 — help, man, etc. (was Re: Using terminal commands - corner cases)

[Multipart message — attachments visible in raw view] — view raw

On 2024-11-27 at 09:28, tomas@tuxteam.de wrote:

> On Wed, Nov 27, 2024 at 02:18:02PM +0000, Eric S Fraga wrote:
> 
>> And, just for the record, should you want to find out more about
>> commands on Linux without leaving your system (i.e. without any
>> interaction with the Internet at all), the man command is available
>> to present the manual pages (dates back to when there was an actual
>> manual in early unix days) for individual commands, e.g.
>> 
>> man bash
>> 
>> which will describe in quite some detail how to use the shell and
>> 
>> man -k somekeyword
>> 
>> will allow to search man pages.
>> 
>> bash itself also has a help system: type "help" :-)
> 
> Good points -- as a tip, turn things around: first try "help foo", 
> then "man foo" whenever you don't know whether what you have is a
> builtin or a command.
> 
> And yes, it's a pity there is no common frontend for both.

There's also 'info foo', which for some values of foo will be more
helpful than either of the above, for others will provide exactly the
same information through a different interface, and for others will
provide no information at all.


This (multiple commands to find the documentation for a command, with no
unified way to look in all the places at once) reminds me of something
that's been in the back of my mind for a long time, and which I've
occasionally gone looking about, but never managed to find an answer on/for.


There is a document which I apparently don't have locally, and don't
remember where I first found, but which is still hosted (in various
formats, none of which are quite what I remember having seen, though the
contents match) in various locations on the current Web. I remember its
having been called "Draft of the UNIX Hierarchy". One location for it
which I find in searching today is:

https://www.cs.earlham.edu/~skylar/humor/Unix/unix.hierarchy.html

Many of the items it lists are obsolete regarding modern usage of,
knowledge of, and familiarity with Linux, and in terms of the
developments in the culture of the use of UNIX and its derivatives over
the time since the document was written, but many of them are still
sufficiently on point to be understandable as reference points. (As a
side note, I would be interested in seeing - and might be interested in
helping to write - an updated version of such a list.)


When I first read this document, there were many references on it which
I did not understand. (One prominent example: I did not know who Dennis,
Bill, and Ken were.) Since then, I have managed to educate myself
sufficiently to be able to understand nearly all of them - with one
prominent exception.

One of the items on the list, under the characteristics of a
"knowledgeable user", is the entry:

* has learned that learn doesn't help

I have never managed to find out what 'learn' is supposed to have been.
No Linux or other *nix-derived system I've ever used has had a command
by that name. I've never managed to find a document which mentions it in
a way that would give a hint as to in what context the term would have
existed, or what it would have been *supposed to* do (whether or not it
actually did it).

Does anyone have an idea what this old reference may be talking about?

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#274934 — Re: help, man, etc. (was Re: Using terminal commands - corner cases)

On Wed, Nov 27, 2024 at 10:40:44 -0500, The Wanderer wrote:
> One of the items on the list, under the characteristics of a
> "knowledgeable user", is the entry:
> 
> * has learned that learn doesn't help
> 
> I have never managed to find out what 'learn' is supposed to have been.
> No Linux or other *nix-derived system I've ever used has had a command
> by that name.

https://www.unix.com/man-page/bsd/1/LEARN/

[toc] | [prev] | [next] | [standalone]

#274939 — Re: help, man, etc. (was Re: Using terminal commands - corner cases)

[Multipart message — attachments visible in raw view] — view raw

On Wed, Nov 27, 2024 at 11:03:48AM -0500, Greg Wooledge wrote:
> On Wed, Nov 27, 2024 at 10:40:44 -0500, The Wanderer wrote:
> > One of the items on the list, under the characteristics of a
> > "knowledgeable user", is the entry:
> > 
> > * has learned that learn doesn't help
> > 
> > I have never managed to find out what 'learn' is supposed to have been.
> > No Linux or other *nix-derived system I've ever used has had a command
> > by that name.
> 
> https://www.unix.com/man-page/bsd/1/LEARN/

Wow :-)

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#274937 — Re: help, man, etc. (was Re: Using terminal commands - corner cases)

[Multipart message — attachments visible in raw view] — view raw

On Wed, Nov 27, 2024 at 10:40:44AM -0500, The Wanderer wrote:
> On 2024-11-27 at 09:28, tomas@tuxteam.de wrote:

[...]

> > And yes, it's a pity there is no common frontend for both.
[help and man]

> 
> There's also 'info foo', which for some values of foo will be more
> helpful than either of the above, for others will provide exactly the
> same information through a different interface, and for others will
> provide no information at all.

The nice thing about info is that it /actually/ falls back to the man
page when no info page is available. So it is a common front-end of
sorts for both. OTOH, the venerable groff has gained a hyperlink markup
recently [1] ("recently" in its time scale), thus bridging yet another
gap separating man and info.

[...]

> * has learned that learn doesn't help

[...]

> Does anyone have an idea what this old reference may be talking about?

Although I did some first Unix steps on a "real" AT&T (a port for M68K),
with ksh (and a vi which dumped core on lines >1K!), I have no clue,
sorry.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#274940 — Re: help, man, etc. (was Re: Using terminal commands - corner cases)

[Multipart message — attachments visible in raw view] — view raw

On 2024-11-27 at 11:59, tomas@tuxteam.de wrote:

> On Wed, Nov 27, 2024 at 10:40:44AM -0500, The Wanderer wrote:
> 
>> On 2024-11-27 at 09:28, tomas@tuxteam.de wrote:

>>> And yes, it's a pity there is no common frontend for both.

> [help and man]

>> There's also 'info foo', which for some values of foo will be more 
>> helpful than either of the above, for others will provide exactly
>> the same information through a different interface, and for others
>> will provide no information at all.
> 
> The nice thing about info is that it /actually/ falls back to the
> man page when no info page is available. So it is a common front-end
> of sorts for both.

...huh. So it does, apparently.

Even at this point I still live and learn. I always thought it was just
that a few particular packages had had their man pages blindly converted
to info format so the packager could ship documentation in both formats.

To be honest, I think I'd kind of rather that it didn't do that... but
it's not like it's hard to recognize the converted-from-man-page
presentation and quit the viewer, when it does happen.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#274941 — Re: help, man, etc. (was Re: Using terminal commands - corner cases)

[Multipart message — attachments visible in raw view] — view raw

On Wed, Nov 27, 2024 at 12:24:25PM -0500, The Wanderer wrote:
> On 2024-11-27 at 11:59, tomas@tuxteam.de wrote:
> 
> > On Wed, Nov 27, 2024 at 10:40:44AM -0500, The Wanderer wrote:
> > 
> >> On 2024-11-27 at 09:28, tomas@tuxteam.de wrote:
> 
> >>> And yes, it's a pity there is no common frontend for both.
> 
> > [help and man]
> 
> >> There's also 'info foo', which for some values of foo will be more 
> >> helpful than either of the above, for others will provide exactly
> >> the same information through a different interface, and for others
> >> will provide no information at all.
> > 
> > The nice thing about info is that it /actually/ falls back to the
> > man page when no info page is available. So it is a common front-end
> > of sorts for both.
> 
> ...huh. So it does, apparently.
> 
> Even at this point I still live and learn. I always thought it was just
> that a few particular packages had had their man pages blindly converted
> to info format so the packager could ship documentation in both formats.
> 
> To be honest, I think I'd kind of rather that it didn't do that... but
> it's not like it's hard to recognize the converted-from-man-page
> presentation and quit the viewer, when it does happen.

It tells you, though. For example, if I do "info ldd", apart from the
giveaway in the heading, as you observe, the footer page says:

  -----Info: (*manpages*)ldd, 65 lines --Top---

So it ain't cheating, honest ;-)

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#274944 — Re: help, man, etc. (was: Re: Using terminal commands - corner cases)

On 27/11/2024 23:59, tomas@tuxteam.de wrote:
> OTOH, the venerable groff has gained a hyperlink markup
> recently [1] ("recently" in its time scale), thus bridging yet another
> gap separating man and info.

Does it affect "man" when called in a terminal application (so usually 
"less" is used as a pager)? At least Emacs and Vim use heuristics with 
plenty of shortcomings to recognize cross-references to other man pages 
(https://manpages.debian.org - debiman works better because it has index 
of man pages from all packages). It is even worse with links to other 
sections and to notes in the same document.

doc-base maintains some document index for yelp/khelpcenter/dhelp/dochelp.

[toc] | [prev] | [next] | [standalone]

#274946 — Re: help, man, etc. (was: Re: Using terminal commands - corner cases)

[Multipart message — attachments visible in raw view] — view raw

On Thu, Nov 28, 2024 at 09:34:24AM +0700, Max Nikulin wrote:
> On 27/11/2024 23:59, tomas@tuxteam.de wrote:
> > OTOH, the venerable groff has gained a hyperlink markup
> > recently [1] ("recently" in its time scale), thus bridging yet another
> > gap separating man and info.
> 
> Does it affect "man" when called in a terminal application (so usually
> "less" is used as a pager)?

Not magically, I guess. I think we'll still need the viewers being able
to "use" the new markup and the footwork of updating the docs.

> At least Emacs and Vim use heuristics with
> plenty of shortcomings to recognize cross-references to other man pages
> (https://manpages.debian.org - debiman works better because it has index of
> man pages from all packages). It is even worse with links to other sections
> and to notes in the same document.
> 
> doc-base maintains some document index for yelp/khelpcenter/dhelp/dochelp.

No, I think that new markup is just a way of replacing the heuristic
with knowledge. The knowledge still has to come in :-)

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#274932

Le 11/27/24 à 15:18, Eric S Fraga a écrit :
> [...] the man command is available to
> present the manual pages


There are also the fine info pages for most gnu software,
notably the coreutils,
and the /usr/share/doc directory for most other software.

Best,

-- 
yassine -- sysadm
+213-779 06 06 23
http://about.me/ychaouche

[toc] | [prev] | [next] | [standalone]

#274935

Eric S Fraga <e.fraga@ucl.ac.uk> wrote:
> And, just for the record, should you want to find out more about
> commands on Linux without leaving your system (i.e. without any
> interaction with the Internet at all), the man command is available to
> present the manual pages (dates back to when there was an actual manual
> in early unix days) for individual commands, e.g.
> 
> man bash
> 
> which will describe in quite some detail how to use the shell and
> 
The bash man page is often rather too lengthy to find what one wants
easily.  For bash built-in commands it's often more useful to try
'help <command>' as you don't then have to wade through the *huge*
bash man page to find what you want.

For example 'help cd' gives a nice man page like summary of how to use
cd.

-- 
Chris Green
·

[toc] | [prev] | [next] | [standalone]

#274929

On Wed, Nov 27, 2024 at 12:55:10 +0100, tomas@tuxteam.de wrote:
> First: cd is not a command, it is a shell builtin
> (this is subtle, but important).

It's both.  You can even call it a "builtin command".

> Second: even if cd were a "command", the splitting
> of args at whitespace (among *a lot* of other things)
> is done by the shell before the command has even a
> chance at it.

Yes.  The shell *parses* each command you type, and among the steps
taken by the parser, one of the most basic is tokenizing the input
into words.

Given a command like this:

    cd /mnt/c/Program Files

the tokenizer breaks it into words:

    [cd] [/mnt/c/Program] [Files]

The first word will be the name of the command to run, and all the
words after that will be arguments passed to the command.

If you want "Program Files" to be treated as a single word, then you
must use quoting.  There are several forms, and they're all acceptable:

    cd "/mnt/c/Program Files"
    cd '/mnt/c/Program Files'
    cd /mnt/c/Program\ Files
    cd /mnt/c/"Program Files"

In all four cases, the tokenizer only sees two words:

    [cd] [/mnt/c/Program Files]

(A second parsing step is quote removal, which discards the quoting
characters that were used to aid the tokenization.)

Also just for the record, bash's tab completion feature is extremely
helpful.  If you type just "cd /mnt/c/Pro" and then press the Tab key,
it will look at the actual file system and find files or directories
that match the current partial word.  If there's only one match, then
it'll type out the rest of the filename for you.  If there are multiple
matches, the behavior depends on your settings.  You may need to press
Tab a second time to get a list of the matches, so that you can type
more characters to make your partial word have only a single match.

When tab completion auto-types a filename with whitespace in it, it'll
use the backslash quoting form to mark the spaces as literal characters
rather than word separators.

[toc] | [prev] | [next] | [standalone]

#274945

On Wed 27 Nov 2024 at 05:38:30 (-0600), Richard Owlett wrote:
> I've used terminal commands for so many decades I don't know where to
> look up fine details of a specific commands.
> 
> I just tried to use the cd command with a target directory having
> spaces in it's name. Of course the system responded
>          > bash: cd: too many arguments
> 
> DuckDuckGo led to [ https://bash.cyberciti.biz/guide/Cd_command#Dealing_with_directories_with_white_space_in_their_names
> ].
> 
> Problem solved. But is there somewhere to go directly without a web search?

Well, it strikes me that, with the exception of Greg's, all these
posts are about man, info, help, etc., which you probably know
about already, whereas what your error above shows is that you
need some passing knowledge of the contents of man bash.

If you find that rather dry and indigestible, you might try running:

  $ wget http://folk.ntnu.no/geirha/bashguide.pdf

which gives you a guide that's designed more for reading than
as a reference document.

BTW I find large man pages a little more navigable by running, eg:

  $ man -t bash | ps2pdf - /tmp/bash.pdf

though that might not be suitable for the OP.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web