Maybe I'm doing something wrong, but the following will make bash
crash.
terminal 2:
$ mkfifo test
$ while true; do echo foo && sleep 1; done > test
terminal 1:
$
The wedding planning can be done easily using like wedding planner,
wedding app etc. It depends upon the wedding planning people to choose
the path, according to their convenient, Budget allocations and their
requirement. The best option to plan the wedding is doing by wedding
couple itself. They c
Le 12/01/2019 à 23:27, Chet Ramey a écrit :
On 1/12/19 1:14 AM, kevin wrote:
Moreover, the explanation in the Bash FAQ is unclear; it lacks examples to
know when "an interference" occurred.
What is "an interference"?
Look at the following answer to get an overview
Le 17/01/2019 à 07:53, kevin a écrit :
Le 12/01/2019 à 23:27, Chet Ramey a écrit :
On 1/12/19 1:14 AM, kevin wrote:
Moreover, the explanation in the Bash FAQ is unclear; it lacks examples to
know when "an interference" occurred.
What is "an interference"?
Look at the
it does not clutter up
the dotfile space of folks who don't use it.
*Kevin O'Gorman (he/him/his)*
CTRL-l, (el), the redraw
screen command in VI does not cause bash to re-read its inputrc file
either. Of course I would be interested to find out what the command is,
but more importantly, I think this information should be provided along
with the emacs information.
Thanks,
Kevin
ed_completion_function = (rl_completion_func_t *)NULL;
+ if (i)
+{
+ old_startup_hook = rl_startup_hook;
+ rl_startup_hook = set_initial_text;
+ initial_text = i;
+}
ret = readline (p);
rl_attempted_completion_function = old_attempted_completion_function;
if (ret == 0)
--
.
fter'
^CTraceback (most recent call last):
File "", line 1, in
KeyboardInterrupt
after
$
dash, mksh, zsh don't exhibit this behaviour: in all cases, execution is
aborted. Bash seems to have always behaved like that, at least since 4.0.
Kevin
On 05/08/2017 15:53, Chet Ramey wrote:
> On 8/4/17 7:52 PM, Kevin Brodsky wrote:
>
>> When Bash receives SIGINT while executing a command, it normally waits
>> for the command to complete, and then aborts execution. However, it
>> looks like somehow, this is not the cas
On 05/08/2017 03:22, Bob Proulx wrote:
> Kevin Brodsky wrote:
>> $ bash -c '(trap "echo INT; exit 1" INT; sleep 60s); echo after'
>> ^CINT
>> after
>> $
> This is a good example of a bad example case. You shouldn't "exit 1"
> or
, POSIX is what it is and we won't change it anyway
;-) For now, there's no other way to communicate with the shell, so
that's fair enough.
> POSIX even added a raise(3) call to make this easier. (Although I
> still do things the old way.)
>
> man 3 raise
That's a good point, it's arguably more self-explanatory than
kill(getpid(), ...).
Kevin
The bug happens to me on
GNU bash, version 4.1.2(2)-release (x86_64-redhat-linux-gnu)
and
GNU bash, version 4.4.12(1)-release (x86_64-apple-darwin16.4.0)
The script is attached, but the function in question is this:
function debug1 {
[ "$debug" ] && echo "$(date "+%Y-%m-%d %H:%M:%S"): $@"
}
e:
>
>
> On Fri, Dec 22, 2017 at 1:39 PM, Kevin Layer wrote:
>
>> The bug happens to me on
>> GNU bash, version 4.1.2(2)-release (x86_64-redhat-linux-gnu)
>> and
>> GNU bash, version 4.4.12(1)-release (x86_64-apple-darwin16.4.0)
>>
>> The script is
Bob,
'set -e' is a double-edged sword, for sure, but I'm not sure it creates
more problems than it solves. Hidden non-zero exits have wasted far more
time, for me, than this little exercise has.
On Sun, Dec 24, 2017 at 11:45 AM, Bob Proulx wrote:
> Kevin Layer wrote:
>
;
dispose_words (list);
I¹ve checked parse.y and the call to expand_prompt_string is correct, so
it looks like you¹ve distributed this version without running bison first.
My machine has bison installed so I¹m not sure why ³make² didn¹t invoke
it.
Best regards
Kevin Broadey
Regarding the response:
> [POSIX] is not necessarily ambiguous, but it does require close
> reading.
Can you please explain how it was concluded that it's a bug based on the
specification?
Thank you
--
Kevin G
s commit is related to the handling of $* when IFS is
unset, but my knowledge of Bash's sources is too limited to tell what's
wrong with it :-)
Kevin
On 20/06/2017 06:33, Eduardo A. Bustamante López wrote:
> On Tue, Jun 20, 2017 at 01:13:07AM +0100, Kevin Brodsky wrote:
> [...]
>> When IFS is unset, unquoted $* undergoes word splitting as if IFS=' ',
>> and not the expected IFS=$' \t\n'. All the other unqu
On 21/06/2017 14:54, Chet Ramey wrote:
> On 6/20/17 1:33 AM, Eduardo A. Bustamante López wrote:
>> On Tue, Jun 20, 2017 at 01:13:07AM +0100, Kevin Brodsky wrote:
>> [...]
>>> When IFS is unset, unquoted $* undergoes word splitting as if IFS=' ',
>>> and n
On 21/06/2017 20:29, Chet Ramey wrote:
> On 6/21/17 2:43 PM, Kevin Brodsky wrote:
>
>> That is also my reading of POSIX (and that's more or less what Bash's
>> manpage says as well), but it doesn't seem to be the case (even in <=4.2):
> That's a rel
&& echo matches
$ [[ ${v} =~ Alphabet ]] && echo matches
matches
$ v="one two buckle my shoe"
$ [[ ${v} =~ "one two" ]] && echo matches
$ [[ ${v} =~ one two ]] && echo matches
$ [[ ${v} =~ one\ two ]] && echo matches
matches
--
Kevin F. Quinn
signature.asc
Description: PGP signature
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
zilla.redhat.com/bugzilla/show_bug.cgi?id=220087)
At least to confirm/deny that it may be a real problem?
Thanks,
--
Kevin F. Quinn
signature.asc
Description: PGP signature
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
== alphabet ]] && echo yes
yes
$ [[ $V == "alphabet" ]] && echo yes
yes
$ [[ $V == 'alphabet' ]] && echo yes
yes
$ [[ $V =~ alphabet ]] && echo yes
yes
$ [[ $V =~ "alphabet" ]] && echo yes
$ [[ $V =~ 'alphabet' ]] &&a
hrough 009 patches
applied (we have a few other local patches for various reasons, but I've
built without them to be sure they're not affecting this). What's the
(7) in the release number - does that refer to difference I might be
missing?
--
Kevin
On Fri, 2 Mar 2007 03:04:14 -0800 (PST)
rleeden <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I struggled recently with a 'while read' type of loop in bash, where
> after the loop had finished the variables used inside the loop are
> not visible any more. I soon found the problem as explained in
> sect
grep, compare for example:
3.1:
$ v="Alphabet"
$ [[ ${v} =~ "^Alpha" ]] && echo matches
matches
$ echo ${v} | grep "^Alpha"
Alphabet
3.2.10
$ v="Alphabet"
$ [[ ${v} =~ "^Alpha" ]] && echo matches
$ echo ${v} | grep "^Alpha"
Alph
On Fri, 09 Mar 2007 11:39:18 -0500
Chet Ramey <[EMAIL PROTECTED]> wrote:
> Kevin F. Quinn wrote:
> > On Mon, 5 Mar 2007 17:49:47 -0500
> > Chet Ramey <[EMAIL PROTECTED]> wrote:
> >
> >> Bash-Release: 3.2
> >> Patch-ID: bash32-010
> >
[AB]=
A=one
B=one two
$ cat show_ab
#!/bin/bash
echo A: $A
echo B: $B
$ A=one B="$A two" ./show_ab
A: one
B: two
$ A=one B="$A two" ./show_ab | more
A: one
B: one two
is a little bizarre. Again; the other shells never yield "one two".
--
Kevin F. Quinn
signature.asc
Description: PGP signature
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
On Sat, 24 Mar 2007 19:32:35 -0400
Chet Ramey <[EMAIL PROTECTED]> wrote:
> Kevin F. Quinn wrote:
> > my interpretation of
> > "variable assignment" is the `A=' part of the statement; i.e. that
> > the rhs of the assignment is expanded.
>
> It
On Sun, 25 Mar 2007 12:26:32 +0200
"Kevin F. Quinn" <[EMAIL PROTECTED]> wrote:
> FWIW I tried also /usr/xpg4/bin/sh (with the Belenix livecd, SunOS
> 5.11) and that shows the same as sh/ash/dash/bb.
FI just tried on SunOS 5.8 (sparc) - a proper Sun installation -
and /usr/x
Following a discussion we had earlier this year regarding the order of
evaluation of variables and variable assignments:
$ A="moo" B="$A more" env |grep ^B
B=moo more
(rather than showing just 'B= more')
the dash maintainer has highlighted the following:
$ bash -c 'K=dvb0.net0 A=${K#dvb} eva
31 matches
Mail list logo
