On 11/11/23 3:05 PM, Greg wrote:
Hello,
I think there may be a minor formatting issue in the set builtin section of the Bash manual
(https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html). In the description of
the "x" option, the second "for" in t
On Sat, Nov 11, 2023 at 08:05:18PM +, Greg wrote:
> Hello,
>
> I think there may be a minor formatting issue in the set builtin section of
> the Bash manual
> (https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html). In
> the description of the "
Hello,
I think there may be a minor formatting issue in the set builtin section of
the Bash manual
(https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html). In
the description of the "x" option, the second "for" in the first sentence is
formatted
On 10/13/23 9:59 AM, Vincent Lefevre wrote:
Hi,
For reports concerning the bash manual, the tarballs (5.2, 5.2.15)
and the Git repository say to Chet Ramey's address (both in the
man page and in the HTML file). But
https://www.gnu.org/software/bash/manual/html_node/Reporting-Bugs.html
Hi,
For reports concerning the bash manual, the tarballs (5.2, 5.2.15)
and the Git repository say to Chet Ramey's address (both in the
man page and in the HTML file). But
https://www.gnu.org/software/bash/manual/html_node/Reporting-Bugs.html
says "Please send all reports conce
Le Mar 31 Mai 2022 10:02:56, chet.ra...@case.edu a écrit :
[...]
> You might tell him that this is standard usage, up to and including
> the
> POSIX standard:
>
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07
>
> I may change this sometime, but it's low prior
hapter with the examples emphasized):
> https://www.gnu.org/software/bash/manual/bash.html#Redirecting-Input
You might tell him that this is standard usage, up to and including the
POSIX standard:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07
I may change this sometime
On Fri, May 20, 2022, at 7:01 PM, Lawrence Velázquez wrote:
> On Fri, May 20, 2022, at 2:06 PM, Therese Godefroy via RT wrote:
>> I'm going to tell him there is no guarantee that this can be changed.
>> For one thing, it would be difficult to find a letter that doesn't
>> take an unwanted meaning w
On Fri, May 20, 2022, at 2:06 PM, Therese Godefroy via RT wrote:
> I'm going to tell him there is no guarantee that this can be changed.
> For one thing, it would be difficult to find a letter that doesn't
> take an unwanted meaning when associated with "word".
Perhaps something like "num" or "fd"
Hello Bash maintainers,
Here is a challenging ticket. The requester complains about the
association of "n" and "word" in "Redirecting Input" (image.png is a
screenshot of this chapter with the examples emphasized):
https://www.gnu.org/software/bash/manual/bash.htm
On 3/24/22 5:15 PM, Zachary Santer wrote:
Thank you.
Also, "append to a array variable" should be "append to an array variable".
Thanks.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc.
Thank you.
Also, "append to a array variable" should be "append to an array variable".
Regards,
Zack
On Thu, Mar 24, 2022 at 3:46 PM Chet Ramey wrote:
> On 3/24/22 11:12 AM, Zachary Santer wrote:
> > I'm consulting the online manual
> > <https:/
On 3/24/22 11:12 AM, Zachary Santer wrote:
I'm consulting the online manual
<https://www.gnu.org/software/bash/manual/html_node/index.html>, so if
you're looking for a version number, that would be 5.1.
I just now looked at doc/bash.pdf in the git repo on Savannah. No info
r 24, 2022 at 11:12 AM Zachary Santer wrote:
> I'm consulting the online manual
> <https://www.gnu.org/software/bash/manual/html_node/index.html>, so if
> you're looking for a version number, that would be 5.1.
>
> I just now looked at doc/bash.pdf in the git re
On Thu, Mar 24, 2022 at 11:12:25AM -0400, Zachary Santer wrote:
> I'm consulting the online manual
> <https://www.gnu.org/software/bash/manual/html_node/index.html>, so if
> you're looking for a version number, that would be 5.1.
>
> I just now looked at doc/bash.
I'm consulting the online manual
<https://www.gnu.org/software/bash/manual/html_node/index.html>, so if
you're looking for a version number, that would be 5.1.
I just now looked at doc/bash.pdf in the git repo on Savannah. No info on
appending is present under bash-5.2-testing or
On Tue, Mar 08, 2022 at 10:55:15AM -0500, Zachary Santer wrote:
> Talking about the lines with "+=", obviously. I only learned I could
> do this when I found it in existing code.
It's mentioned in the PARAMETERS section:
uated. When += is applied to an array variable using compound assig
$ array=( zero one two )
$ array+=( three four five )
$ declare -p array
declare -a array='([0]="zero" [1]="one" [2]="two" [3]="three"
[4]="four" [5]="five")'
$ array=( [0]=zero [1]=one [2]=two )
$ array+=( [3]=three [4]=four [5]=five )
$ declare -p array
declare -a array='([0]="zero" [1]="one" [2]
On 2021-12-13 at 11:23 +, Kerin Millar wrote:
> You mentioned being confused by how the and's and or's combine. The
> wording of the bash man page seems marginally less ambiguous in that
> regard, partly owing to its sparse use of the comma.
>
> "An interactive shell is one started without non
On 12/16/21 1:33 PM, fatiparty--- via Bug reports for the GNU Bourne Again
SHell wrote:
>
> Have been reading the Gnu Bash Manual "6.7 Arrays" and there is no mention of
> ${#name[*]} to get the array size.
"${#NAME[SUBSCRIPT]}' expands to the length of
'${N
Have been reading the Gnu Bash Manual "6.7 Arrays" and there is no mention of
${#name[*]} to get the array size.
ot;started without any arguments, or with option arguments only"
Just to muddy the waters further, the POSIX Utility Syntax Guidlines [1]
employs a different terminology. What the bash manual refers to as a
"non-option argument" is, instead, an "operand". On the other han
On Mon, Dec 13, 2021 at 8:31 AM Mallika wrote:
> "An interactive shell is one started without non-option arguments, unles*s*
> -s is specified, without specifying the -c option, and whose input and
> error output are both connected to terminals (as determined by isatty(3)), or
> one started with
#x27;d actually decided to write in just to clarify that first line:
>> > "started without non-option arguments,"
>> >
>> > Does "option arguments" mean "option*al* arguments"?
>>
>> No. While all option arguments happen to be optional
fy that first line:
> > "started without non-option arguments,"
> >
> > Does "option arguments" mean "option*al* arguments"?
>
> No. While all option arguments happen to be optional, not all
> optional arguments are options.
>
> An &
uments"?
No. While all option arguments happen to be optional, not all
optional arguments are options.
An "option argument", roughly speaking, is an argument that begins
with one or two hyphen-minuses and affects the configuration of the
invoked shell. They are described here:
htt
ref:
https://www.gnu.org/software/bash/manual/html_node/What-is-an-Interactive-Shell_003f.html
"An interactive shell is one started without non-option arguments, unles*s*
-s is specified, without specifying the -c option, and whose input and
error output are both connected to terminal
On 5/18/21 2:44 PM, Ingo wrote:
Hello,
during my job related reentry into bash scripting after 23 years of work with
other platforms (e.g. mainframes) I made some extensions/changes to a printed
version of bash manual edition 4.4 of 2016 which might be useful also for
others.
Thanks for
Hello,
during my job related reentry into bash scripting after 23 years of work with
other platforms (e.g. mainframes) I made some extensions/changes to a printed
version of bash manual edition 4.4 of 2016 which might be useful also for
others.
Here are they:
Page 18, section 3.4 Shell
On 6/29/20 6:27 AM, 홍홍 wrote:
> In 4.3.2 The Shopt Builtin,
>
> The statement below appears twice redundantly.
>
> The return status when listing options is zero if all optnames are enabled,
> non-zero otherwise. When setting or unsetting options, the return status is
> zero unless an optname i
In 4.3.2 The Shopt Builtin,
The statement below appears twice redundantly.
The return status when listing options is zero if all optnames are enabled,
non-zero otherwise. When setting or unsetting options, the return status is
zero unless an optname is not a valid shell option.
On 6/16/20 8:34 AM, 홍홍 wrote:
> In this section
> https://www.gnu.org/software/bash/manual/bash.html#Shell-Parameter-Expansion
> <https://www.gnu.org/software/bash/manual/bash.html#Shell-Parameter-Expansion>
> (substring expansion)
>
> If offset is 0, and the positi
In this section
https://www.gnu.org/software/bash/manual/bash.html#Shell-Parameter-Expansion
<https://www.gnu.org/software/bash/manual/bash.html#Shell-Parameter-Expansion>
(substring expansion)
If offset is 0, and the positional parameters are used, $@ is prefixed to the
list.
should
On Sat, May 25, 2019 at 02:56:43PM -0400, Richard Marmorstein wrote:
> There was discussion on Twitter today
> (https://twitter.com/PttPrgrmmr/status/1132351142938185728) about how the
> Bash manual appears to not be indexable by search engines.
>
> https://www.gnu.org/softw
There was discussion on Twitter today
(https://twitter.com/PttPrgrmmr/status/1132351142938185728) about how the
Bash manual appears to not be indexable by search engines.
https://www.gnu.org/software/bash/manual/bashref.html
redirects to
https://www.gnu.org/savannah-checkouts/gnu/bash/manual
On 3/23/19 2:54 PM, Craig Miles wrote:
> Hi all:
>
> There's some inadvertently repeated text in doc/bashref.info which is
> propagating into all manuals generated therefrom. Lines 1900 and 1901 in
> the v5.0 version.
Thanks for the report. This was fixed in the devel branch about two months
ago
Hi all:
There's some inadvertently repeated text in doc/bashref.info which is
propagating into all manuals generated therefrom. Lines 1900 and 1901 in
the v5.0 version.
the rules described below (*note Pattern Matching::). If the
pattern matches If the pattern matches a trailing portion of the
On 3/12/19 4:26 PM, Todd Lehman wrote:
> On Tue, 12 Mar 2019, Chet Ramey wrote:
>> On 3/11/19 4:55 PM, Todd Lehman wrote:
>>> Hi!
>>>
>>> In the version dated 2019-Jan-07, I noticed the following mistake in the
>>> GNU Bash manual:
>>>
>&
On Tue, 12 Mar 2019, Chet Ramey wrote:
On 3/11/19 4:55 PM, Todd Lehman wrote:
Hi!
In the version dated 2019-Jan-07, I noticed the following mistake in the
GNU Bash manual:
| Associative arrays are created using
| declare -A name.
The period (".") after "name" should not
On 3/11/19 4:55 PM, Todd Lehman wrote:
> Hi!
>
> In the version dated 2019-Jan-07, I noticed the following mistake in the
> GNU Bash manual:
>
> | Associative arrays are created using
> | declare -A name.
>
> The period (".") after "name" sh
Date:Mon, 11 Mar 2019 23:15:14 -0500
From:Todd Lehman
Message-ID:
| In any case, please fix as you see fit.
First, to make one thing clear, I have nothing whatever to do
with maintaining bash (for reasons unrelated to anything here,
I won't even go close to its so
On Mar 11, 2019, at 11:03 PM, Robert Elz wrote:
> No, it was fine, I understood the context OK - it is just that this
> is one of those rock and hard place situations - the places where
> there is no period to end a sentence can just as easily be argued
> to be incorrect.
I would argue that reada
Date:Mon, 11 Mar 2019 22:08:47 -0500 (CDT)
From:Todd Lehman
Message-ID:
| Ah. Maybe my initial e-mail wasn't clear.
No, it was fine, I understood the context OK - it is just that this
is one of those rock and hard place situations - the places where
there is no p
On Tue, 12 Mar 2019, Robert Elz wrote:
| The period (".") after "name" should not be there.
Yet, the rules of grammar say it must be, as that is the end of the
sentence.
Ah. Maybe my initial e-mail wasn't clear. The second line is was actual
code sample. It's formatted as verbatim, monosp
Date:Mon, 11 Mar 2019 15:55:55 -0500 (CDT)
From:Todd Lehman
Message-ID:
| The period (".") after "name" should not be there.
Yet, the rules of grammar say it must be, as that is the end of the
sentence. This is the perennial issue with mixing code samples into
E
Hi!
In the version dated 2019-Jan-07, I noticed the following mistake in the
GNU Bash manual:
| Associative arrays are created using
| declare -A name.
The period (".") after "name" should not be there.
--Todd
Chet,
BTW, After your reply, I was curious who case.edu was, but I'm seeing
this (in both of my browsers):
Is your main university server down?
On 12/19/2017 09:08 AM, Chet Ramey wrote:
On 12/19/17 12:23 PM, Howard Johnson wrote:
Hi,
In section:
3.5.1 Brace Expansion
The line,
On 12/19/17 12:23 PM, Howard Johnson wrote:
> Hi,
>
> In section:
> 3.5.1 Brace Expansion
>
> The line,
> "To avoid conflicts with parameter expansion, the string ‘${’ is not
> considered eligible for brace expansion."
>
> occurs twice.
Thanks for the catch.
Chet
--
``The lyf so shor
Hi,
In section:
3.5.1 Brace Expansion
The line,
"To avoid conflicts with parameter expansion, the string ‘${’ is
not considered eligible for brace expansion."
occurs twice.
In the documentation for the "mapfile" builtin command:
'-C'
Evaluate CALLBACK each time QUANTUMP lines are read. The '-c'
option specifies QUANTUM.
"QUANTUMP" should be "QUANTUM".
In the latest sources cloned from git://git.savannah.gnu.org/bash.git, this
occurs in:
b
his
> fashion as well).
>
> [1]
> https://www.gnu.org/software/bash/manual/bash.html#Controlling-the-Prompt
Thanks for the report. The man page is clearer that PS0, PS1, PS2, and
PS4 undergo prompt string expansions. I'll see what the info document
needs.
--
``The lyf so short, t
The manual says [1]:
In addition, the following table describes the special characters which can
appear in the prompt variables PS1 to PS4:
..which misses PS0 (and seems to imply that PS3 gets expanded in this
fashion as well).
[1] https://www.gnu.org/software/bash/manual/bash.html
On 9/6/16 11:19 AM, jean lewis wrote:
> line1949: \fBdeclare\fP or \fBlocal\fP
Thanks for the report. This was fixed a while back.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.edu
2015-09-21 08:49:42 -0400, Greg Wooledge:
> On Mon, Sep 21, 2015 at 07:45:25PM +0800, ziyunfei wrote:
> > "Functions may be exported so that *subshells* automatically have them
> > defined with the -f option to the export builtin"
> >
> > Technically, a child shell process forked/execed by the cu
On Mon, Sep 21, 2015 at 07:45:25PM +0800, ziyunfei wrote:
> "Functions may be exported so that *subshells* automatically have them
> defined with the -f option to the export builtin"
>
> Technically, a child shell process forked/execed by the current shell is not
> a real subshell, am I right?
"Functions may be exported so that *subshells* automatically have them defined
with the -f option to the export builtin"
Technically, a child shell process forked/execed by the current shell is not a
real subshell, am I right?
Hi GNU,
There appears to be a logical bug in the Bash Manual
<http://www.gnu.org/software/bash/manual/bash.html#Definitions>.
It claims that an operator is:
"a control operator or a redirection operator. [...] Operators contain at
> least one unquoted metacharacter."
Neat!
Hello.
In the latest version of online manual for gnu bash,
in chapter "4.3.1 The Set Builtin"
(https://www.gnu.org/software/bash/manual/html_node/The-Set-Builtin.html)
there is obscure explanation to option "-a".
The sentence says "Mark variables and function which ar
Found word 'seqeunce' instead of 'sequence' in:
http://www.gnu.org/software/bash/manual/html_node/Brace-Expansion.html#Brace-Expansion
VBR,
Vincent.
Hello,
in bash.texi, node Bourne Shell Builtins, documentation for unset:
-- replace "remvoved" with "removed"
In node "Shell parameters"
1507 A variable can be assigned the @var{nameref} attribute using the
1508 @option{-n} option to the \fBdeclare\fP or \fBlocal\fP builtin commands
1509 (@px
On 2014-03-02 06:30:07 -0800, Ryan Cunningham wrote:
> Apparently I am not reading it wrong. Read my previous e-mail to this
> list on this thread.
If you had paid attention and looked at my reply more closely, you would
have noticed that the e-mail was not even addressed to you, it was
addressed
Apparently I am not reading it wrong. Read my previous e-mail to this list on
this thread.
Sent from my iPad
> On Mar 1, 2014, at 8:55 PM, Chris Down wrote:
>
>> On 2014-03-01 11:29:03 -0800, Dave Yost wrote:
>> In http://www.gnu.org/software/bash/manual/bashref.html#GNU-Par
On 2014-03-01 11:29:03 -0800, Dave Yost wrote:
> In http://www.gnu.org/software/bash/manual/bashref.html#GNU-Parallel
>
> Where you say
> ls *.gz | parallel -j+0 "zcat {} | bzip2 >{.}.bz2 && rm {}"
> This will recompress all files in the current directory wit
Hmmm. That doesn't seem right. Actually, the original statement is correct.
Sent from my iPad
> On Mar 1, 2014, at 11:29 AM, Dave Yost wrote:
>
> In http://www.gnu.org/software/bash/manual/bashref.html#GNU-Parallel
>
> Where you say
> ls *.gz | parallel -j+0 "zc
In http://www.gnu.org/software/bash/manual/bashref.html#GNU-Parallel
Where you say
ls *.gz | parallel -j+0 "zcat {} | bzip2 >{.}.bz2 && rm {}"
This will recompress all files in the current directory with names ending in
.gz using bzip2, running one job per CPU (-j+0) in pa
Hello,
> [ariy...@gmail.com - Tue Jun 25 16:04:34 2013]:
>
> Hello.
> I have found a little difference between bash behaviour and it's
> description in manual.
>
> According to the info from the url
> http://www.gnu.org/software/bash/manual/html_node/Word-
Am 06.03.2013 01:03, schrieb Linda Walsh:
>
> John Kearney wrote:
>> The example is bad anyway as you normally don't want to parallelize disk
>> io , due to seek overhead and io bottle neck congestion. This example
>> will be slower and more likely to damage your disk than simply using mv
>> on its
John Kearney wrote:
> The example is bad anyway as you normally don't want to parallelize disk
> io , due to seek overhead and io bottle neck congestion. This example
> will be slower and more likely to damage your disk than simply using mv
> on its own. but thats another discussion.
---
ply using mv
on its own. but thats another discussion.
with regards to nit picking, considering how much effort is made on this
mailing list and help-bash to give filename safe examples, its hardly
nitpicking to expect the examples in the bash manual to be written to
the same standard.
> this is actually more disturbing.
>
> ls | parallel mv {} destdir
>
> find -type f -print0 | xargs -0 -I{} -P /bin/mv {}
If we're really going to pick nits here, those two aren't really identical.
You'd probably want something like
find . -depth 1 \! -name '.*' -print0
to start.
Chet
--
I'm getting a chance to look at this.
> this is actually more disturbing.
>
> ls | parallel mv {} destdir
That's straight from the parallel manual. Pretty much all of the examples
are from the parallel manual.
Ole Tange, GNU parallel's author, supplied the text and examples. It
would be more
Am 26.02.2013 03:36, schrieb Linda Walsh:
>
> Chet Ramey wrote:
>> On 2/25/13 8:07 PM, Linda Walsh wrote:
>>> Chet Ramey wrote:
On 2/16/13 3:50 AM, Pierre Gaston wrote:
> I don't quite see the point of having gnu parallel discussed in the
> bash reference manual.
I was asked to ad
Chet Ramey wrote:
> On 2/25/13 8:07 PM, Linda Walsh wrote:
>> Chet Ramey wrote:
>>> On 2/16/13 3:50 AM, Pierre Gaston wrote:
I don't quite see the point of having gnu parallel discussed in the
bash reference manual.
>>> I was asked to add that in May, 2010 by Ole Tange and Richard Stall
Chet Ramey wrote:
> On 2/16/13 3:50 AM, Pierre Gaston wrote:
>> I don't quite see the point of having gnu parallel discussed in the
>> bash reference manual.
> I was asked to add that in May, 2010 by Ole Tange and Richard Stallman.
Maybe now that it was done, it can be removed?
Or did they as
On Sun, Feb 17, 2013 at 4:54 PM, Chet Ramey wrote:
> On 2/16/13 9:57 AM, Chris Down wrote:
>
> > Count me also in favour of removal of this section. At best the entire
> > section needs a complete rewrite, but why on earth we have a whole
> section
> > dedicated to a nonstandard external tool is
On 2/16/13 9:57 AM, Chris Down wrote:
> Count me also in favour of removal of this section. At best the entire
> section needs a complete rewrite, but why on earth we have a whole section
> dedicated to a nonstandard external tool is kind of baffling.
Consider the FSF's perspective. The fact tha
On 2/16/13 3:50 AM, Pierre Gaston wrote:
> I don't quite see the point of having gnu parallel discussed in the
> bash reference manual.
> http://www.gnu.org/software/bash/manual/bashref.html#GNU-Parallel
I was asked to add that in May, 2010 by Ole Tange and Richard Stallman.
Chet
On 16 February 2013 20:54, John Kearney wrote:
> Am 16.02.2013 09:50, schrieb Pierre Gaston:
> > I don't quite see the point of having gnu parallel discussed in the
> > bash reference manual.
> > http://www.gnu.org/software/bash/manual/bashref.html#GNU-Parallel
> >
Am 16.02.2013 09:50, schrieb Pierre Gaston:
> I don't quite see the point of having gnu parallel discussed in the
> bash reference manual.
> http://www.gnu.org/software/bash/manual/bashref.html#GNU-Parallel
> I don't argue that it can be a useful tool, but then you might as
I don't quite see the point of having gnu parallel discussed in the
bash reference manual.
http://www.gnu.org/software/bash/manual/bashref.html#GNU-Parallel
I don't argue that it can be a useful tool, but then you might as well
discuss sed awk grep make find etc..
Or even the ones not p
>From my point of view in the section REDIRECTION of the man manual there
is something technically incorrect:
/dev/tcp/host/port
If host is a valid hostname or Internet address, and port
is an integer port number or service name, bash attempts
to open a TCP connection to the correspon
t; uname output: Linux woodpecker 2.6.22-hardened-r8 #1 SMP Fri Oct 26 17:51:28
> UTC 2007 i686 Intel(R) Xeon(TM) CPU 3.00GHz GenuineIntel GNU/Linux
> Machine Type: i686-pc-linux-gnu
>
> Bash Version: 4.1
> Patch Level: 7
> Release Status: release
>
> Description:
> $ [[ xx$(
.00GHz GenuineIntel GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 4.1
Patch Level: 7
Release Status: release
Description:
$ [[ xx$(echo -e $'\E')xx == xx$(echo -e '\e')xx ]] && echo "true"
$ true
Fix:
Mention it in bash manual.
On 5/27/11 10:15 AM, Mu Qiao wrote:
> Bash Version: 4.1
> Patch Level: 9
> Release Status: release
>
> Description:
> We haven't checked bash-4.0 but for bash-4.1 and later, without
> options, unset first tries to unset a variable, and if that fails, tries
> to unset a function. However, The ma
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-pc-linux-gnu-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/sha
On 3/11/10 9:10 AM, Robert Cratchit wrote:
> On page
>
> http://www.gnu.org/software/bash/manual/bashref.html#Bash-Startup-Files
>
> Could this sentence:
>
> "An interactive shell is one started without non-option arguments,
> unless -sis specified, without specifyi
On Fri, Mar 12, 2010 at 12:39 PM, Pierre Gaston wrote:
>
>
> On Fri, Mar 12, 2010 at 12:15 PM, Ken Irving wrote:
>
>> On Fri, Mar 12, 2010 at 11:57:41AM +0200, Pierre Gaston wrote:
>> > On Fri, Mar 12, 2010 at 11:50 AM, Ken Irving
>> wrote:
>> >
>> > > On Fri, Mar 12, 2010 at 09:16:05AM +, Ma
On Fri, Mar 12, 2010 at 12:15 PM, Ken Irving wrote:
> On Fri, Mar 12, 2010 at 11:57:41AM +0200, Pierre Gaston wrote:
> > On Fri, Mar 12, 2010 at 11:50 AM, Ken Irving
> wrote:
> >
> > > On Fri, Mar 12, 2010 at 09:16:05AM +, Marc Herbert wrote:
> > > > >> Could this sentence:
> > > > >>
> > >
On Fri, Mar 12, 2010 at 11:57:41AM +0200, Pierre Gaston wrote:
> On Fri, Mar 12, 2010 at 11:50 AM, Ken Irving wrote:
>
> > On Fri, Mar 12, 2010 at 09:16:05AM +, Marc Herbert wrote:
> > > >> Could this sentence:
> > > >>
> > > >> "An interactive shell is one started without non-option argument
On Fri, Mar 12, 2010 at 11:50 AM, Ken Irving wrote:
> On Fri, Mar 12, 2010 at 09:16:05AM +, Marc Herbert wrote:
> > >> Could this sentence:
> > >>
> > >> "An interactive shell is one started without non-option arguments,
> > >> unless -sis specified, without specifying the
> > >> -c option, a
On Fri, Mar 12, 2010 at 12:50:26AM -0900, Ken Irving wrote:
> On Fri, Mar 12, 2010 at 09:16:05AM +, Marc Herbert wrote:
> > >> Could this sentence:
> > >>
> > >> "An interactive shell is one started without non-option arguments,
> > >> unless -sis specified, without specifying the
> > >> -c opt
On Fri, Mar 12, 2010 at 09:16:05AM +, Marc Herbert wrote:
> >> Could this sentence:
> >>
> >> "An interactive shell is one started without non-option arguments,
> >> unless -sis specified, without specifying the
> >> -c option, and whose input and error output are both connected to terminals
>
>> Could this sentence:
>>
>> "An interactive shell is one started without non-option arguments,
>> unless -sis specified, without specifying the
>> -c option, and whose input and error output are both connected to terminals
>> (as determined by isatty(3)), or one started with the -i option. "
>>
>
On Thu, Mar 11, 2010 at 09:10:11AM -0500, Robert Cratchit wrote:
> On page
>
> http://www.gnu.org/software/bash/manual/bashref.html#Bash-Startup-Files
>
> Could this sentence:
>
> "An interactive shell is one started without non-option arguments,
> unless -sis spec
On page
http://www.gnu.org/software/bash/manual/bashref.html#Bash-Startup-Files
Could this sentence:
"An interactive shell is one started without non-option arguments,
unless -sis specified, without specifying the
-c option, and whose input and error output are both connected to terminal
Maybe a format error:
"3.6 Redirections" section' subsections all has same 'href' attribute
"#Redirections".
Found it on http://www.gnu.org/software/bash/manual/bashref.html.
--
Yecheng Fu (Cofyc)
http://yechengfu.com
Subject:WWW: tar.file incolplete in
http://www.gnu.org/software/bash/manual/
Date: Sat, 15 Aug 2009 01:58:27 +0300
To: g...@gnu.org
From: Jari Aalto
Download (untitled)
text/plain 1.8k
At page
> http://www.gnu.org/software/bash/manual
There is bashref.info.tar.gz which is
> 2009 x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 3.2
> Patch Level: 39
> Release Status: release
>
> Description:
> The bash manpage doesn't document the -n option. It is mentioned with
> the -D option, but not documented its
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKA
- Original Message -
From: "Chet Ramey" <[EMAIL PROTECTED]>
To: "Stahlman Family" <[EMAIL PROTECTED]>
Cc: ; <[EMAIL PROTECTED]>
Sent: Tuesday, December 12, 2006 2:01 PM
Subject: Re: Despite text in gnu bash manual, quote removal appears to be
1 - 100 of 106 matches
Mail list logo
