and does not launch the three processes.
I feel that the expansion should be protected wheither wrapped or not to
preserve the expected results.
Please keep me posted on this bug.
Michael
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Please remove the extra line spacing between items in the main table of
contents. While it looks reasonable in the HTML version, it looks
dreadful in the info viewer and is inconsistent with the other tables
of links.
Configuration Information [Automatically generated, do not change]:
Machine: i3
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='ba
"rltty.c", line 398.1: 1506-485 (S) Parameter declaration list is
incompatible with declarator for rltty_warning.
make[1]: *** [Makefile:72: rltty.o] Error 1
make: *** [Makefile:663: lib/readline/libreadline.a] Error 1
/opt/bin/make returned an error
make -i compiles the rest of the files. Obvious
Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i586-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='ba
33868
prw--- 1 aixtools staff 0 Mar 11 08:07
/tmp/sh-np-21233868-1115804781
prw--- 1 aixtools staff 0 Mar 11 08:07
/tmp/sh-np-21233868-3761770506
Getting back to AdoptOpenJDK - a build process has roughly 3750 of these
commands - leaving 7500 files behind i
On 11/03/2021 22:27, Chet Ramey wrote:
On 3/11/21 3:55 PM, Michael Felt (aixtools) wrote:
Sent from my iPhone
On 11 Mar 2021, at 18:15, Chet Ramey wrote:
On 3/11/21 11:28 AM, Michael Felt wrote:
Hi,
Issue: AdoptOpenJDK build process makes bash calls in a particular
way. An
On 16/03/2021 14:38, Chet Ramey wrote:
On 3/16/21 8:04 AM, Michael Felt wrote:
Decided to give bash-5.1 a try. I doubt it is major, but I get as far
as:
"../../../src/bash-5.1.0/lib/sh/tmpfile.c", line 289.11: 1506-068 (W)
Operation between types "char*" and "int&q
On 16/03/2021 16:21, Chet Ramey wrote:
On 3/16/21 11:07 AM, Michael Felt wrote:
On 16/03/2021 14:38, Chet Ramey wrote:
On 3/16/21 8:04 AM, Michael Felt wrote:
Decided to give bash-5.1 a try. I doubt it is major, but I get as
far as:
"../../../src/bash-5.1.0/lib/sh/tmpfile.c", l
On 11/03/2021 18:11, Chet Ramey wrote:
On 3/11/21 11:28 AM, Michael Felt wrote:
Hi,
Issue: AdoptOpenJDK build process makes bash calls in a particular
way. An abbreviated (shorter pathnames) example is:
```
bash-5.0$ /usr/bin/printf "Building targets 'product-images
legacy-jre-
(pathname);
if (fd < 0)
{
/* Two separate strings for ease of translation. */
On 17/03/2021 16:17, Michael Felt wrote:
On 11/03/2021 18:11, Chet Ramey wrote:
On 3/11/21 11:28 AM, Michael Felt wrote:
Hi,
Issue: AdoptOpenJDK build process makes bash calls in a particular
way.
27;returns' - it ends via sh_exit() and the end of the routine.
Next time - I'll save all of my debug changes. Got a bit too rigorous
when I cleaned up.
On 17/03/2021 19:03, Chet Ramey wrote:
On 3/17/21 11:52 AM, Michael Felt wrote:
OK - this process on github has not gone exactly as
On 17/03/2021 23:12, Chet Ramey wrote:
On 3/17/21 3:29 PM, Michael Felt wrote:
I tried as many combinations of commands as I could - and it seems
that the regular behavior of dup2 on the opened fifo is enough to
maintain communication.
It's not, since FIFOs exist in the file system and
Scraping through this - thanks for the lessons aka explanations.
On 18/03/2021 16:08, Chet Ramey wrote:
On 3/18/21 5:53 AM, Michael Felt wrote:
Yes, something to test. Thx. The ojdk scenario is: /usr/bin/printf >
>(tee -a stdout.log) 2> >(tee -a stderr.log).
So, yes, in thi
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-a6qmCk/bash-5.0=.
-fstack-protector-stron>
uname output: Linux ubuntu 5.4.0-73-generic #82-Ubuntu SMP Wed Apr 14 17:39:42
UTC 2
Sounds great to me. I also use Bash for mission-critical processes.
Philip
On Mon, Jul 4, 2022 at 8:22 AM Yair Lenga wrote:
>
> Hi,
>
> In my projects, I'm using bash to manage large scale jobs. Works very well,
> especially, when access to servers is limited to ssh. One annoying issue is
> the e
He has a point, though. To have some of the functionality of jq inside Bash
may be very useful.
If he can supply a patch, why not?
Philip Orleans
On Sun, Aug 28, 2022, 3:22 PM John Passaro wrote:
> interfacing with an external tool absolutely seems like the correct answer
> to me. a fact worth m
There is an additional problem with IFS and the command read
Suppose I have variable $line with a string "a,b,c,d"
IFS=',' read -r x1 <<< $line
Bash will assign the whole line to x1
echo $x1
line="a,b,c,d";IFS=',' read -r x1 <<< $line;echo $x1;
a,b,c,d
but if I use two variables
line="a,b,c,d";I
I support this feature.
On Sat, Nov 11, 2023, 11:29 AM Corto Beau wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2
> uname output: Linux zinc 6.6.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 08
>
On Sat, Feb 5, 2011 at 17:51, Bob Proulx wrote:
> Are you thinking that setting shopts should in some way be persistent
> across program invocations? That would be pretty annoying and a
> severe bug if it did.
>
> Are you forgetting to put your desired configuration into ~/.bashrc
> where it is l
On Sat, Feb 5, 2011 at 15:56, Slevin McGuigan
wrote:
> I am unsure whether or not this a bug.
>From what I can tell, it's not so much a bug as it is an inadequacy:
When you quit bash, the history is stored very naively in "$HISTFILE";
the history is simply dumped to it line-by-line, and each line
On Sat, Feb 5, 2011 at 18:02, Jon Seymour wrote:
> The version I tried on Linux 3.2.25 does have a .bash_history
> format that could support it, but it still behaved the same way.
How do you mean?
I'm running bash version "4.1.9(2)-release" on GNU/Linux, and the
resulting history file doesn't se
On Sat, Feb 5, 2011 at 19:15, Jon Seymour wrote:
> Here's the format I see in my history.
>
> #1296950184
> for i in 1 2
> do
> echo $i
> done
> #1296950194
> exit
>
> HISTTIMEFORMAT is:
>
> HISTTIMEFORMAT='[%m.%d.%y] %T '
>
>
> bash -version is:
>
> GNU bash, version 3.2.25(1)-release (i686-red
On Sat, Feb 5, 2011 at 20:02, Michael Witten wrote:
> So, if you run `history', you'll not only get the commands in the
> history list, but you'll also get the time at which the commands
> were last run (formatted according to "$HISTTIMEFORMAT").
>
> In oth
On Sat, Feb 5, 2011 at 20:12, Jon Seymour wrote:
> You don't have to do that - the timestamp is encoded in a "comment"
> line between entries. See the example below. One could simply assume
> all lines between two lines beginning with # are part of the one
> entry,
That's what I was saying.
Howe
On Sat, Feb 5, 2011 at 20:09, Jon Seymour wrote:
> I guess the point is that in versions of bash that do store the
> timestamp in the .bash_history file
To clarify, the timestamp is stored whenever HISTTIMEFORMAT has a
non-null value; the bash version doesn't particularly matter unless
you're sug
On Wed, Feb 9, 2011 at 08:53, Ingo Molnar wrote:
>
> * Michael Witten wrote:
>
>> On Mon, Feb 7, 2011 at 07:08, Oleg Nesterov wrote:
>> > Now that it is clear what happens, the test-case becomes even more
>> > trivial:
>> >
>> >
variable i.e:
$ echo \$PWD/
The shell-expand-line (Ctrl-Alt-e) works but before I could use just TAB
Any hints why? Any way to get the 4.1 behavior in 4.2?
Can someone confirm... Is this a bug or a feature?
Thanks in advance
Michael
2011/2/27 Clark J. Wang
>
> A workaround is fine but is the 4.2 behavior bug or not?
>
I agree...Would be nice if someone could confirm if this is a bug or not?
I'm betting that this is a bug :-)
//Michael
The parse_token_word() function (parse.y:4297) has a couple of off-by-one
assignments to the `token' array, which are really 2 manifestations of the
same bug.
These patches first mask the bug by solving the manifestations independently,
and then eradicate the bug by uniformly dismantling the noodl
pinion, this is wrongheaded, but it only requires the change of
one character and it's exactly what other code paths in read_token_word()
[currently] do, probably by mistake. :-P
Signed-off-by: Michael Witten
---
parse.y |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/
_buffer_size,
TOKEN_DEFAULT_GROW_SIZE);
This patch achieves that final result by deflating the `room' value by 1,
from `ttranslen + 2' to `ttranslen + 1'.
Signed-off-by: Michael Witten
---
parse.y |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
dif
t requirement, thereby "masking"
the bug.
In my opinion, this is wrongheaded, but it only requires the change of
one character and it's exactly what other code paths in read_token_word()
[currently] do, probably by mistake. :-P
Signed-off-by: Michael Witten
---
pars
Signed-off-by: Michael Witten
---
parse.y |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/parse.y b/parse.y
index b61c4d0..eaae077 100644
--- a/parse.y
+++ b/parse.y
@@ -4453,7 +4453,7 @@ read_token_word (character)
{
peek_char = shell_getc (1
Signed-off-by: Michael Witten
---
parse.y |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/parse.y b/parse.y
index a12c4d0..b61c4d0 100644
--- a/parse.y
+++ b/parse.y
@@ -4538,17 +4538,13 @@ read_token_word (character)
shell's single-char
ansparent understanding).
Signed-off-by: Michael Witten
---
parse.y | 36 +---
1 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/parse.y b/parse.y
index 38c4330..a12c4d0 100644
--- a/parse.y
+++ b/parse.y
@@ -4382,7 +4382,7 @@ read_token_word (ch
On looking over this patch, I found a number of `bugs' in my description,
but they don't change the conclusions. I should have proofread more carefully.
On Sat, 26 Feb 2011 11:48:06 -0500, Michael Witten wrote:
> /** simulate peek_char and parse_matched_pair() **/
&g
On looking over this patch, I found a number of `bugs' in my description,
but they don't change the conclusions. I should have proofread more carefully.
On Sat, 26 Feb 2011 09:48:06 -0700, Michael Witten wrote:
> /** simulate peek_char and parse_matched_pair() **/
&g
.gnu.org/software/bash/manual/html_node/Shell-Expansions.html#Shell-Expansions
says:
3.5.4 Command Substitution
--
...
... When using the `$(COMMAND)' form, all characters between
the parentheses make up the command; none are treated
specially.
...
If the substitution appears within double quotes, word
splitting and filename expansion are not performed on the
results.
Could somebody please tell me what's going on here?
Sincerely,
Michael Witten
On Sat, Apr 2, 2011 at 08:20, Andreas Schwab wrote:
> Brace expansion.
HAH! :-D
Damn :-/
word is expanded.
and this:
... When using the `$(COMMAND)' form, all characters between
the parentheses make up the command; none are treated
specially.
So, there should be no brace expansion in this case, because
the entire brace construct is quoted:
'{sub(/a/,$0)}'
Thus, bash has a bug.
My guess is the nature of the problem is that the combination
of the outer-most quotes (which would render most characters
as literal) and the command substitution (which in some sense
is probably parsed in a `top-level' context) works to confuse
the brace-expansion logic.
Sincerely,
Michael Witteng
On Mon, May 30, 2011 at 02:18, Bradley M. Kuhn wrote:
> Chet Ramey wrote on 2009-11-02:
>> Jari Aalto was setting up a git repository of current and older bash
>> versions on savannah. I'll keep him up to date with public versions
>> of bash
>
> Bob Proulx wrote on 2009-11-02:
>>> It looks like i
On Mon, May 30, 2011 at 03:09, Bradley M. Kuhn wrote:
>
> Michael Witten replied a few minutes ago:
>> it is my opinion that all further development should take place through
>> a public, distributed repository such as the one you have created -
>> regardless of Chet&#x
On Mon, May 30, 2011 at 05:06, Ben Pfaff wrote:
> "Bradley M. Kuhn" writes:
>
>> The new repository contains everything that the current
>> Savannah one does, but I put much more effort into making
>> commits fine-grained, rather than merely importing the public
>> releases blindly. (For example
On Thu, Jun 2, 2011 at 17:00, Bradley M. Kuhn wrote:
> I'd suggest that we keep the master branch only to track the history of
> releases and officially released patches as Chet posts them, and then we
> can use separate branches for individual developers who want to use Git.
> What do you think o
>On Thu, Jun 2, 2011 at 17:00, Bradley M. Kuhn wrote:
>> I'd suggest that we keep the master branch only to track the history of
>> releases and officially released patches as Chet posts them, and then we
>> can use separate branches for individual developers who want to use Git.
>> What do you th
On Fri, Jun 3, 2011 at 15:27, Bradley M. Kuhn wrote:
> Sorry, I was imprecise in my wording in my email yesterday. By "use
> separate branches for individual developers", I meant that "branches
> would be created for those developers who wanted to develop publicly in
> a Git repository".
Such de
On Mon, Jun 13, 2011 at 17:10, Bradley M. Kuhn wrote:
> I have all my bash history going back to
> 2003-10-15 accessible to me.
Why?
On Mon, Aug 8, 2011 at 18:44, Linda Walsh wrote:
>
> I was testing functions in my shell, I would cut/paste,
> thing is, with each past, I'd get my dir listed (sometimes multiple times)
> on each line entered.
>
> Now I have:
> shopt:
> no_empty_cmd_completion on
>
> i.e. it's not supposed to exp
On Mon, 8 Aug 2011 21:40:39 +0200, Davide Brini wrote:
> On Mon, 8 Aug 2011 21:14:50 +0200, Davide Brini wrote:
>
>> In fact, you could do the same thing with
>>
>> foo() { # hit tab here
>>
>> and I'm sure you wouldn't consider that an empty line.
>
> I have to take that back: it looks like
On Mon, 08 Aug 2011 15:56:30 -0700, Linda Walsh wrote:
> Michael Witten wrote:
>>
>> In any case, even if `no_empty_cmd_completion' were to behave as Linda
>> expected, her tabs would still get eaten when pasted on the interactive
>> command line.
>
> Which
On Sat, Aug 13, 2011 at 23:41, Linda Walsh wrote:
> ${#${!name}[*]}
> bash: ${#${!name}[*]}: bad substitution
It's probably what you're trying to avoid, but you'll probably have to
construct and then eval the right code by hand:
$(eval "echo \${#$name[*]}")
On Sun, Aug 14, 2011 at 00:49, Dennis Williamson
wrote:
> On Sat, Aug 13, 2011 at 6:41 PM, Linda Walsh wrote:
>>
>>
>>
>> I want to have an array of 'names'.
>>
>> given a name, "X", I had a prefix, _p_, so have _p_X,
>> I want to access / manipulate it as an array.
>>
>> so given I pass in a na
On Sun, Aug 14, 2011 at 04:55, Linda Walsh wrote:
>
>
>
> ` Michael Witten wrote:
>>
>> On Sat, Aug 13, 2011 at 23:41, Linda Walsh wrote:
>>
>>>
>>> ${#${!name}[*]}
>>> bash: ${#${!name}[*]}: bad substitution
>>>
>>
&
On Sun, Aug 14, 2011 at 05:56, Michael Witten wrote:
> On Sun, Aug 14, 2011 at 04:55, Linda Walsh wrote:
>>
>>
>>
>> ` Michael Witten wrote:
>>>
>>> On Sat, Aug 13, 2011 at 23:41, Linda Walsh wrote:
>>>
>>>>
>>>>
sorry, i forgot something.
2531c2531
< "Führt eine eingebeute Shell Funktionen aus.\n"
---
> "Führt eine eingebaute Shell Funktionen aus.\n"
2539c2539
< "Der Rückgabewert der eingebauten Schellfunkrion oder Falsch, wenn\n"
---
> "Der Rückgabewert der eingebauten Shell Funktion oder Fal
Hello,
Hope i am right here with that.
Nothing special, but noticed this just now. Patch is attached.
I am not registered in this list, so please cc replys to me.
Greetings,
Michael
2539c2539
< "Der Rückgabewert der eingebauten Schellfunkrion oder Falsch, wenn\n"
---
On Mon, Sep 12, 2011 at 14:19, Roger wrote:
>> On Mon, Sep 12, 2011 at 08:36:07AM -0400, Greg Wooledge wrote:
>>On Sun, Sep 11, 2011 at 11:23:48PM -0800, Roger wrote:
>>> When using GNU Screen (or other terminal multiplexer), I noticed the
>>> terminal
>>> multiplexer never gives each bash shell
B.t.w I have the bind 'set show-all-if-ambiguous on' so I only need to
press once.
Bug or feature? Any hints?
Thanks in advance,
Michael
> On 2/24/11 5:14 PM, Michael Kalisz wrote:
>
>> Bash Version: 4.2
>> Patch Level: 0
>> Release Status: release
>>
t', which executes `source file2' in the current shell context,
which creates the variable `v1' in the current shell context, but
creates the variables `v2' and `v3' local to the function being
executed in the current shell context, so that by the echo statement,
only `v1' is defined.
Sincerely,
Michael Witten
Configuration Information [Automatically generated, do not change]:
Machine: powerpc
OS: aix5.3.0.0
Compiler: powerpc-ibm-aix5.3.0.0-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='powerpc'
-DCONF_OSTYPE='aix5.3.0.0' -DCONF_MACHTYPE='powerpc-ibm-aix5.3.0.0'
-DCONF_VENDOR='ibm' -DLOCALE
On 07/24/2012 05:49 PM, Greg Wooledge wrote:
> On Tue, Jul 24, 2012 at 05:03:36PM +0200, michael.haubenwall...@salomon.at
> wrote:
>> Description:
>> On AIX (5.3, 6.1, 7.1), as well as on Interix (any version) I do
>> encounter
>> some race condition in a code similar to:
>> i
On 07/25/2012 03:05 AM, Chet Ramey wrote:
> Bash assumes that there's a PID space at least as
> large as CHILD_MAX, and that the kernel will use all of it before reusing
> any PID in the space. Posix says that shells must remember up to CHILD_MAX
> statuses of terminated asynchronous children (th
On 07/25/2012 09:59 AM, Michael Haubenwallner wrote:
> On 07/25/2012 03:05 AM, Chet Ramey wrote:
>> Bash holds on to the status of all terminated processes, not just
>> background ones, and only checks for the presence of a newly-forked PID
>> in that list if the list s
On 07/25/2012 02:14 PM, Greg Wooledge wrote:
> On Wed, Jul 25, 2012 at 09:59:28AM +0200, Michael Haubenwallner wrote:
>> OTOH, AFAICT, as long as a PID isn't waitpid()ed for, it isn't reused by
>> fork().
>> However, I'm unable to find that in the POSIX s
On 07/25/2012 03:20 PM, Michael Haubenwallner wrote:
> On 07/25/2012 09:59 AM, Michael Haubenwallner wrote:
>> On 07/25/2012 03:05 AM, Chet Ramey wrote:
>>> Bash holds on to the status of all terminated processes, not just
>>> background ones, and only checks for the
On 07/25/2012 04:50 PM, Chet Ramey wrote:
>> The AIX 6.1 I've debugged on has:
>> #define CHILD_MAX 128
>> #define _POSIX_CHILD_MAX 25
>> sysconf(_SC_CHILD_MAX) = 1024
> Bash prefers sysconf(_SC_CHILD_MAX) and will use it over the other
> defines (lib/sh/oslib.c:getmaxchild()). I don't kno
On 07/25/12 19:06, Chet Ramey wrote:
Well, _SC_CHILD_MAX is documented across platforms as:
Heck, even POSIX specifies CHILD_MAX as:
"Maximum number of simultaneous processes per real user ID."
Also, one Linux machine actually shows the _SC_CHILD_MAX value equal to
kernel.pid_max (32768 here
On 07/26/12 20:29, Chet Ramey wrote:
OK, we have some data, we have a hypothesis, and we have a way to test it.
Let's test it.
Michael, please apply the attached patch, disable RECYCLES_PIDS, and run
your tests again. This makes the check for previously-saved exit statuses
uncondit
On 07/26/2012 11:37 PM, Michael Haubenwallner wrote:
> On 07/26/12 20:29, Chet Ramey wrote:
>> OK, we have some data, we have a hypothesis, and we have a way to test it.
>> Let's test it.
>>
>> Michael, please apply the attached patch, disable RECYCLES_PIDS, an
On 07/29/2012 12:46 AM, Chet Ramey wrote:
> On 7/27/12 9:50 AM, Michael Haubenwallner wrote:
>
>> With attached patch I haven't been able to break the testcase below so far
>> on that AIX 6.1 box here.
>>
>> But still, the other one using the $()-childs still
On 08/28/2012 09:21 AM, Roman Rakus wrote:
> On 08/01/2012 03:13 PM, Chet Ramey wrote:
>> On 7/30/12 10:41 AM, Roman Rakus wrote:
>>
>>> Hmm... I don't know much about boundaries of maximum number of user
>>> processes. But anyway - do you think that (re)changing js.c_childmax (when
>>> `ulimit -u
and print out. However after the fork the command executed ("ls") seems to be
unable to access stdin, stdout, stderr and goes into defunct.
Any help or guidance is appreciated, is there somewhere in the source code of
bash that would point me in the right direction?
Thanks
Michael
Hi,
I have a complaint. Apparently, when unknowingly attempting to run a
32-bit executable file on a 64-bit computer, bash gives the error message
"No such file or directory". That error message is baffling and frustratingly
unhelpful. Is it possible for bash to provide a better error message
in t
library needed for file or interpreter cannot be
found."?
Thanks,
-Mike
On 1/1/13, Aharon Robbins wrote:
> In article ,
> Michael Williamson wrote:
>>Hi,
>>
>>I have a complaint. Apparently, when unknowingly attempting to run a
>>32-bit executable file
-- Forwarded message --
From: Eric Blake
Date: Wed, 02 Jan 2013 10:41:07 -0700
Subject: Re: No such file or directory
To: Michael Williamson
On 01/02/2013 10:30 AM, Michael Williamson wrote:
> Hi Eric,
>
> Thanks for your explanation. I realize now that I should
&g
<>
When /dev/fd is missing, and named pipes are used instead (like on AIX),
this snippet sometimes does work right, wrong, or hang - depending on
the operating system's process scheduler timing:
for x in {0..9}; do echo $x; done > >(
cnt=0; while read line; do let cnt=cnt+1; done; echo $cnt
)
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
On 11/14/2013 08:56 PM, Chet Ramey wrote:
> On 11/8/13 6:26 PM, John Dawson wrote:
>> The following surprised me. I thought line 4 of the output, and certainly
>> line 5 of the output, should have said "0 /dev/fd/63" too. Is this behavior
>> a bug?
>
> I'm still looking at this. I have not had a
Hi!
On 11/28/2013 02:32 PM, Flene TOUMANI wrote:
> Is it possible to get a feedback on the issue? (E.g. a confirmation that this
> is a bug).
Sounds like you've run into this problem (patch available):
http://lists.gnu.org/archive/html/bug-bash/2013-10/msg00114.html
/haubi/
Hi
It seems that the binding for Alt-Tab changed from dynamic-complate-history
to tab-insert around Bash 3.0.
The bashref.info file as found in Debian and the current version 3.0 Bash
source tarball on http://ftp.gnu.org/gnu/bash/ both still state the default
binding for dynamic-complete-his
Hello, Shell Community
My name is Michael Song
Recently I found shell is a nice program that can be extended to solve my
automatic regression test problem. So I started hacking it.
I found it would be easiler use $(wildcard) in the builtins/Makefile.in, in
stead of staticly specify all the
In the SHELL GRAMMAR section of the bash man page, the [[ expression ]]
syntax is described:
When the == and != operators are used, the string to the right of the
operator is
considered a pattern and matched according to the rules described below
under Pattern Matching.
The P
Chet Ramey <[EMAIL PROTECTED]> writes:
> q. Extensive changes to readline to add enough state so that commands
> requiring additional characters (searches, multi-key sequences, numeric
> arguments, commands requiring an additional specifier character like
> vi-mode change-char, etc.)
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: i386-redhat-linux-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linu
x-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDI
R='/usr/s
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: linux-gnu
Compiler: i386-redhat-linux-gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linu
x-gnu' -DCONF_MACHTYPE='i386-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDI
R='/usr/
ctory! Yay!"
else
echo "$i is not a directory!"
fi
}
done
Regards,
Michael
On Sep 12, 2007, at 2:56 AM, Bob Proulx wrote:
The [ is a shell builtin, not a shell
metacharacter. Shell metacharacters do not need to be separated by
whitespace but the test program needs to be apart or it won't be
parsed right. That is why you are seeing "[-d" not found. It is not
a paren
t
doing a bit more getting familiar.
Best Regards All!
Michael
Group,
I have having a problem with spaces in individual elements of an array.
The space causes a single element to be seen as multiple elements.
Here is a sample run:
-
[EMAIL PROTECTED]:~/bin> ./arraywithspace.sh
3.1.17(1)-release
got 6 parm
exhaustive test because this solution will work for me.
--
potter
On Nov 10, 2007 12:27 PM, Andreas Schwab <[EMAIL PROTECTED]> wrote:
> "Michael Potter" <[EMAIL PROTECTED]> writes:
>
> > countparms ${Arguments[*]}
>
> Use "[EMAIL PROTECTED]" instead
ory
Fix: (patch attached)
builtins/common.c:
Do not depend on getcwd() doing buffer allocation.
config-bot.h:
Ignore GETCWD_BROKEN, keep HAVE_GETCWD as is.
Additionally, the check for GETCWD_BROKEN can be dropped
from configure.in and aclocal.m4.
Thanks!
/haubi/
--
Micha
On Thu, 2007-12-20 at 12:30 +0100, Andreas Schwab wrote:
> Michael Haubenwallner <[EMAIL PROTECTED]> writes:
>
> > diff -ru builtins/common.c builtins/common.c
> > --- builtins/common.c Wed Dec 19 10:30:07 2007
> > +++ builtins/common.c Wed Dec 19 10:34
On Thu, 2007-12-20 at 08:08 -0500, Chet Ramey wrote:
> Michael Haubenwallner wrote:
> > Machine: i586
> > OS: interix5.2
> > Compiler: gcc
> > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
> > -DCONF_OSTYPE='interix5.2&#
On Fri, 2007-12-21 at 13:51 +0100, Michael Haubenwallner wrote:
> On Thu, 2007-12-20 at 08:08 -0500, Chet Ramey wrote:
> > Michael Haubenwallner wrote:
> > > Machine: i586
> > > OS: interix5.2
> > > Compiler: gcc
> > > Compilation CF
On Sat, 2007-12-22 at 10:13 -0500, Chet Ramey wrote:
> Michael Haubenwallner wrote:
> >> It is because readdir() returns 0 (zero) for (struct dirent).(d_ino),
> >> while stat() returns useful values for (struct stat).(st_ino), so their
> >> equal-comparison never suc
On Wed, 2008-01-23 at 17:45 +0100, Philippe De Muyter wrote:
> here is a patch :
LOL - this is a very similar patch as
http://lists.gnu.org/archive/html/bug-bash/2007-12/msg00084.html
/haubi/
--
Michael Haubenwallner
Gentoo on a different level
It is not a bug in bash. it is just how it works. the while loop
creates a subshell and changes to the variables are not visable
outside of the subshell. if you put the while loop first, then it
will not create the subshell.
do this:
result=""
while read line; do
extracteddata=`echo "$
Bash Bunch,
Not surprisingly, bash does not exit the script when an error is detected in
a subshell.
I am hopeful that someone has a solution to this (other than: be careful to
not use subshells).
Here is the test run:
---
./subshellnofail.sh
BEGIN
ERROR: ./subshellnofail.sh 10
1 - 100 of 186 matches
Mail list logo
