网络推广优惠活动,
新浪竟价返点45.SOHU竟价返点35.TOM竟价返点45.
百度竟价返点35.3721竟价78折.中搜竟价75折
新浪,SOHU,163固定排名65折.TOM固定65折.
通用网址6折，3721实名65折，百度火暴地带75折
HAO123首页广告文字连接
国际域名50,.CN域名40
QQ314544899 [EMAIL PROTECTED]
电话:010--86657920 张先生
___
Bug-bash mailing list
Bug-bash@gnu
Very often Bash 5.2 would suddenly stop saving command history which
has been confusing me for quite some time. Today I did some debugging
and came up with the following minimal scenario to reproduce the
problem.
$ bash --version
GNU bash, version 5.2.0(18)-beta (x86_64-apple-darwin21.5.0)
Copyri
Hello
In bash-5.2, There is one modification: fix to expand $'...' and
$"..." in certain word expansions while expanding lines of here-document data
This modification has been changed when dealing with '$(', It seems
to have missed the right bracket. Maybe we should add this bracket.
I hope
On 12/13/22 12:42 PM, wang yuhang wrote:> This modification has
been changed when dealing with '$(', It seems > to have missed the
right bracket. Maybe we should add this bracket.
It seems that there is something wrong with this patch, It's tru
Hello !
I am now doing a test on the fork bomb with the command `:(){:|:&};:` and
set `ulimit - c 1000`. And everything was well in bash-5.0, but there was a
problem in bash-5.1.
The main performance is that the system memory has been rising, and then the
kernel appears the oom, I found that
> First, systemd will send a sigterm to bash, but in bash-5.1, the bash
process will not be killed. this was caused by a > > > change in bash
5.1. The modified change information is as follows
> ```
> sss. Fix a bug where receiving SIGTERM from a different process while
readline was active could
See the following example (with 5.2.15):
bash-5.2$ PS1='$? >> '
0 >> eval '`'
bash: unexpected EOF while looking for matching ``'
0 >><-- press ENTER
2 >><-- now $? is 2
It looks like the failed eval '`' is still waiting for some input?
hi
I accidentally copied a section of JSON text to the terminal and executed it,
which resulted in a system crash.Bash version is 5.1.8.
Later, I reproduced it and found that when I executed the following command,
the memory usage of bash became very large.
$
[{"key":"1","key":"1","key"
Hi
I found that there is a huge difference in performance between different
versions of bash when there are a large number of environment variables in my
system.
The steps to reproduce are as follows??
$ for i in `seq 1`; do export TEST_ENV_$i=$i; done
$ time echo `date`
In bash-4.3, it
On Wed, Nov 8, 2017 at 9:46 PM Chet Ramey wrote:
> On 11/7/17 11:38 PM, Clark Wang wrote:
>
> > I made a patch (also attached). Please see if it's ok.
> >
> >
> > Updated by dealing with empty strings (and malloc'ing 2 more bytes)
> >
commit 4214b0e12b4345c970d4d50705b1443441baedf8
Author: Chet Ramey
Date: Fri 2023-11-10 05:39:38 +0800
Bash-5.2 patch 16: fix for a crash if one of the expressions in an
arithmetic for command expands to NULL
M execute_cmd.c
M patchlevel.h
A tags
I guess it's not intenti
Hi
A bash coredump has appeared in my environment, the stack information displayed
by GDB is as follows:
#0 __pthread_kill_implementation (threadid=
> Hi. This appears to happen when creating a shell variable from the initial
> environment. I can't reproduce it. If you can find a way to reliably
> reproduce it, please let me know and we can work on it.
I'm sorry, the environment is quite complex and I couldn't find a way to
reliably reproduc
> Hi. This appears to happen when creating a shell variable from the initial
> environment. I can't reproduce it. If you can find a way to reliably
> reproduce it, please let me know and we can work on it.
So far, we have encountered this issue three times in our environment. The
following is one
> The initialize_shell_variables function is processing env. When the for
loop
> reaches env[16], glibc needs to use the main_arena.top variable. However,
the
> value in the address pointed to by the top variable is overwritten by
env[15],
> causing a glibc exception and resulting in a cor
> Is this at the same point as the core dump in your previous message?
yes
uppercase: abcabc --> incorrect
replace the first "a" to uppercase: Abcabc --> correct
replace all "a" to uppercase: AbcAbc--> correct
Repeat-By:
--
Jerry Wang jerry.j.w...@alcatel-lucent.com
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash
uot;%c\n", 65'
A
Perhaps bash should clarify this issue in its documents such that users like me
would not be misguided again.
Thanks
2011/6/23 Jonathan Nieder :
> Hi,
>
> Yunfeng Wang wrote:
>
>> $ printf %c 65 66 67
>> 666
>>
>> T
Thanks Jan, Greg's solution is great!
wyf
2011/6/23 Jan Schampera :
> Hi,
>
>
> I agree this is not a bug. %c works as described.
>
> However, Mr. Wang may want to read one of Greg's brilliant FAQ entries [1].
>
> In general it's a bit of a pity that print
On Tue, Apr 10, 2012 at 16:38, Elliott Forney wrote:
> On Tue, Apr 10, 2012 at 1:22 AM, Maarten Billemont
> wrote:
> > People should stop trying to execute code by parameter expansion, and
> specifically stop thinking that parameter-expanded words are evaluated as
> bash code.
>
> I still think t
On Wed, May 5, 2010 at 01:57, Freddy Vulto wrote:
> It appears that `unset' is capable of traversing down the call-stack and
> unsetting variables repeatedly:
>
>a=0 b=0 c=0 d=0 e=0
>_unset() { unset -v b c c d d d e; }
>t1() {
>local a=1 b=1 c=1 d=1
>t2
>}
>t2
On Wed, Apr 25, 2012 at 07:21, Ted Okuzumi wrote:
> I am writing this e-mai to report to report a bug in bash.
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
On Fri, Apr 27, 2012 at 02:02, Bill Gradwohl wrote:
>
> So, if you want to make sure a sub
> function can't touch a variable, put another function in between that
> localises and then unsets the variable.
>
Sounds interesting. Will see if I can take advantage of this in future. :)
>
>
> --
> Bi
On Fri, Apr 27, 2012 at 02:49, Greg Wooledge wrote:
>
> I don't see this as a surprise. It's how you return values from functions
> in bash. Pick a global variable (r, ret, whatever you want) and stuff the
> return value into that. You can even declare your "r" locally somewhere
> so that the
On Sat, Jun 2, 2012 at 7:39 AM, rac8006 wrote:
>
> What is the proper way to add popd pushd dirs etc to bash. When I currently
> build bash these
By default those commands should be enabled. I never added special
options when buidling Bash. Not sure if it's system dependent. But
from the "config
On Mon, May 28, 2012 at 11:32 PM, John E. Malmberg wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=825751
>
> bash-4.2.24-1.fc16.i686
>
> Steps to Reproduce:
> 1. Activate a terminal running a bash shell
> 2. ls $HOME/
> 3.
>
> Actual results:
> ls \$HOME/
Already discussed for quite a few t
On Mon, Jun 25, 2012 at 3:18 PM, Niels Carl W. Hansen <
re...@aauindy.cscaa.dk> wrote:
>
> Description:
>[[ 'foobar' =~ 'o.a' ]] && echo FOUND
>should print FOUND but it doesn't.
>This have worked in previeous versions of bash.
>The bash used comes with CentOS 6.
For quite a long time I don't know why my bash stops remembering command
history. I just figured out it was caused by some code like `eval return'
in the .bashrc/.bash_profile.
Steps to reproduce (tested with 3.2.25, 4.0.28, 4.1.11 and 4.2.29):
$ cp .bashrc .bashrc.old
$ echo eval return > .bashr
On Tue, Sep 4, 2012 at 7:13 PM, Roman Rakus wrote:
> Hi,
> Petr, adding to cc: list, found behaviour not documented, neither in man
> page nor bash ref manual:
> ${par-word} will do expansion of par, and if the par is unset it is
> substituted by word. It is different from ${par:-word}, where wor
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: darwin12.0.0
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='darwin12.0.0' -DCONF_MACHTYPE='i386-apple-darwin12.0.0'
-DCONF_VENDOR='apple' -DLOCALEDIR='/alien/share/loca
On Wed, Oct 17, 2012 at 5:18 AM, wrote:
>
> Bash Version: 4.2
> Patch Level: 37
>
> Description:
>
> bash -c 're=".*([0-9])"; if [[ "foo1" =~ ".*([0-9])" ]]; then echo
> ${BASH_REMATCH[0]}; elif [[ "bar2" =~ $re ]]; then echo ${BASH_REMATCH[0]};
> fi'
>
> This should output foo1. It instead outpu
See following example:
$ cat foo.sh
u=root
echo ~$u
$ bash foo.sh # bash 4.2.37
~root
$ ksh foo.sh # ksh 93u+ 2012-08-01
/root
$
Anyone can explain/confirm what should be the correct behavior?
-Clark
On Wed, Nov 14, 2012 at 7:57 PM, Roman Rakus wrote:
> On 11/14/2012 04:00 AM, Clark WANG wrote:
>
>> In ksh:
>>
>> $ printf '%(%F %T)T\n'
>> 2012-11-14 10:57:26
>> $
>>
>> In bash:
>>
>> $ printf '%(%F %T)T\n'
>&
On Wed, Nov 21, 2012 at 6:40 AM, smu johnson wrote:
> Hi.
>
> If you are in regular emacs mode in Bash, and you hit Esc twice, it acts as
> an auto-complete, similar to just hitting tab.
>
> I cannot find this behaviour in any of the system wide bash defaults in
> /etc, or any of my own dotfiles.
On Sat, Jan 26, 2013 at 1:27 PM, Linda Walsh wrote:
> I noted on the bash man page that it says it will start in posix
> compliance mode when started as 'sh' (/bin/sh).
>
> What does that mean about bash extensions like arrays and
> use of [[]]?
>
> Those are currently not-POSIX (but due to both
On Mon, Jan 28, 2013 at 3:07 PM, Egmont Koblinger wrote:
> Hi folks,
>
> Sometimes I work with quite long command lines (4-5 lines on the screen)
> and I need to modify something somewhere in the middle. I know a couple of
> ways to move the cursor there a little bit faster than holding the left
On Tue, Jan 21, 2014 at 8:16 AM, Elliott Forney wrote:
> I find it a little unpleasant that cd echoes the new working directory
> when CDPATH is used to locate the new directory (I already have the
> working directory in my prompt). I understand that this is behavior
> is mandated by POSIX but I
For example in 4.3 when direxpand is enabled, `cd ./tmp' would be
expand `./tmp' to the full path (e.g. `/root/tmp/'). I think this is not
good especially when the full dir path is very long. Bash 4.2 (tested with
4.2.37) does not behave like this. Could we keep the 4.2 behavior?
-clark
On Sat, Mar 15, 2014 at 12:06 AM, Chet Ramey wrote:
> On 3/14/14 2:39 AM, Clark Wang wrote:
> > For example in 4.3 when direxpand is enabled, `cd ./tmp' would be
> > expand `./tmp' to the full path (e.g. `/root/tmp/'). I think this is not
> > good especially
See following example with bash-4.3.11 (compiled with the default configure
option):
[STEP 101] $ complete -r
[STEP 102] $ shopt direxpand
direxpand on
[STEP 103] $ find .
.
./the-dir
./the-dir/file
./the dir
./the dir/file
[STEP 104] $ foo the-
[STEP 104] $ foo the-dir/
[STEP 104] $ foo the
See following example with bash-4.3.11:
[STEP 101] $ mkdir -p "foo's dir/dir1/dir2"
[STEP 102] $ complete -d cd
[STEP 103] $ cd
[STEP 103] $ cd foo\'s\ dir/
The 1st worked fine but the 2nd failed to work. Bash 4.2.47 and 4.1.9
behaved the same.
-clark
On Sat, Apr 26, 2014 at 3:41 AM, Chet Ramey wrote:
> On 4/23/14, 11:21 PM, Clark Wang wrote:
> > See following example with bash-4.3.11:
> >
> > [STEP 101] $ mkdir -p "foo's dir/dir1/dir2"
> > [STEP 102] $ complete -d cd
> > [STEP 103] $ cd
See following example:
$ echo $BASH_VERSION
4.3.18(1)-release
$ compgen -W 'hello hello' h
hello
hello
$
It'll be good if only one "hello" is outputted.
-clark
On Mon, Sep 8, 2014 at 1:07 AM, Chet Ramey wrote:
> On 9/4/14, 10:33 PM, Clark Wang wrote:
> > See following example:
> >
> > $ echo $BASH_VERSION
> > 4.3.18(1)-release
> > $ compgen -W 'hello hello' h
> > hello
> > hello
> &g
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='linux-gnu
' -DCONF_MACHTYPE='i386-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/sh
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='linux-gnu'
-DCONF_MACHTYPE='i386-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/sha
When using Bash, I often turn on the `completion-ignore-case' option of
readline. It works fine for most cases but sometimes it does not work as
expected when completing the first word on the command line. For example,
there is a bash script ~/MyDir/Foo.sh, on command line, when I input ~/my
and th
On Feb 17, 2008 5:21 AM, Chet Ramey <[EMAIL PROTECTED]> wrote:
> Jian Wang wrote:
> > When using Bash, I often turn on the `completion-ignore-case' option of
> > readline. It works fine for most cases but sometimes it does not work as
> > expected when completi
On Feb 18, 2008 3:59 AM, Chet Ramey <[EMAIL PROTECTED]> wrote:
> Jian Wang wrote:
> > On Feb 17, 2008 5:21 AM, Chet Ramey <[EMAIL PROTECTED]
> > <mailto:[EMAIL PROTECTED]>> wrote:
> >
> > Jian Wang wrote:
> > > When using Bash, I oft
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linu
x-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/
local/share/locale' -DPACKA
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linu
x-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/
local/share/locale' -DPACKA
On Fri, Oct 31, 2008 at 14:59, Chris F.A. Johnson <[EMAIL PROTECTED]>wrote:
> On 2008-10-31, Clark J. Wang wrote:
> ...
> > # read line <&11<--- test with fd 11
> > bash: 11: Bad file descriptor
> > #
>
> You haven't opened file des
On Fri, Oct 31, 2008 at 14:18, Clark J. Wang <[EMAIL PROTECTED]> wrote:
> Hi, all:
>
> When I was doing some testing I found the file descriptor 10 is always
> duplicate of fd 0 and it cannot be closed.
>
> See the following commands:
>
> # echo $BASH_VERSION
>
See:
${parameter@operator}
Parameter transformation. The expansion is either a
transforma-
tion of the value of parameter or information about
parameter
itself, depending on the value of operator. Each operator
is a
single letter:
On Fri, Oct 27, 2017 at 3:00 AM, Eli Barzilay wrote:
> On Thu, Oct 26, 2017 at 2:02 PM, Chet Ramey wrote:
> >
> > It's more of a general statement about arrays, though it appears in
> > the paragraph that discusses unset, so it's in the man page section on
> > arrays. You have to be careful abo
On Fri, Oct 27, 2017 at 1:17 PM, Eli Barzilay wrote:
>
> I already said why `unset` is different. If it wasn't clear, a direct
> example is the fact that `delete` in javascript is a special syntax
> rather than a function. To make it more confusing, the other obvious
> place where an lvalue app
See following example:
[STEP 100] # echo $BASH_VERSION
4.4.12(2)-release
[STEP 101] # v=\'\'
[STEP 102] # printf '%q\n' "$v"
\'\'
[STEP 103] # printf '%s\n' "${v@Q}"
''\'''\'''
[STEP 104] #
On Fri, Oct 27, 2017 at 3:28 PM, Eli Barzilay wrote:
> On Fri, Oct 27, 2017 at 2:37 AM, Clark Wang wrote:
> >
> > What `unset' does is special but there's nothing special when parsing
> > the command and bash even does not care if it's built-in command or
&
See following example:
[STEP 100] # echo $BASH_VERSION
4.4.12(2)-release
[STEP 101] # v=abc
[STEP 102] # printf '%q\n' $v
abc
[STEP 103] # printf '%s\n' "${v@Q}"
'abc'
[STEP 104] #
Is it possible to not quote the result since there's no special chars in
the string? I would expect ${var@Q} to prod
On Mon, Oct 30, 2017 at 10:41 PM, Chet Ramey wrote:
>
> This is an effect of using single quotes in the @Q operator. If you want
> to single-quote a string containing single quotes, this is how you do it.
>
I made a patch (also attached). Please see if it's ok.
Tested with arr=('' a \' \'\' \'\
On Tue, Oct 31, 2017 at 3:25 PM, Clark Wang wrote:
> On Mon, Oct 30, 2017 at 10:41 PM, Chet Ramey wrote:
>
>>
>> This is an effect of using single quotes in the @Q operator. If you want
>> to single-quote a string containing single quotes, this is how you do it.
>
For now the `declare' command is under SHELL BUILTIN COMMANDS in the man
page so people may think bash parses the command line parameters the same
way as other built-in commands which is not true.
[STEP 100] # echo $BASH_VERSION
4.4.12(4)-release
[STEP 101] # declare -a arr=()
[STEP 102] #
On Mon, Oct 30, 2017 at 8:35 PM, Greg Wooledge wrote:
>
> What's the bug? They are equivalent.
>
It's not a bad thing if we can make the language a bit more elegant unless
the cost is not worth it.
>
> If you mean "I would like bash to perform a second optimization pass
> over the result of ${
On Tue, Oct 31, 2017 at 3:53 PM, Clark Wang wrote:
> On Tue, Oct 31, 2017 at 3:25 PM, Clark Wang wrote:
>
>> On Mon, Oct 30, 2017 at 10:41 PM, Chet Ramey wrote:
>>
>>>
>>> This is an effect of using single quotes in the @Q operator. If you want
>>&g
[STEP 100] # echo $BASH_VERSION
4.4.12(4)-release
[STEP 101] # bind -m vi-insert '"jj": "\e\e"'
[STEP 102] # bind -X
"jj": "\e\e"
[STEP 103] # bind -r jj
[STEP 104] # bind -X
[STEP 105] # <-- Here when I press j it still waits for about 1 second
to show up.
See following example:
[STEP 100] # echo $BASH_VERSION
4.4.12(4)-release
[STEP 101] # set -- $'\001'
[STEP 102] # v=$*
[STEP 103] # printf '%q\n' "$v"
$'\001\001'
[STEP 104] #
On Mon, Jan 15, 2018 at 11:44 PM, Chet Ramey wrote:
> On 1/15/18 1:26 AM, Clark Wang wrote:
> > See following example:
> >
> > [STEP 100] # echo $BASH_VERSION
> > 4.4.12(4)-release
> > [STEP 101] # set -- $'\001'
> > [STEP 102] # v=$*
> > [S
On Wed, Jan 24, 2018 at 2:23 AM, Daniel Colascione
wrote:
> Right now, PROMPT_COMMAND gives a shell command to run before displaying
> the prompt. It's common these days to include in one's bash configuration
> numerous packages from different sources that *all* want to run code at
> PROMPT_COMMA
On Thu, Feb 8, 2018 at 9:05 PM, Jaan Vajakas wrote:
> Hi!
>
> I noticed a weird behavior. Is it a bug?
>
> Namely, why does
>
> echo "$(for f in a b c; do if [[ \"$f\" > b ]]; then echo "$f > b"; else
> echo "$f <= b"; fi; done)"
>
Should be:
echo "$(for f in a b c; do if [[ $f > b ]]; then e
On Mon, Feb 12, 2018 at 2:45 PM, Nikolai Kondrashov
wrote:
> On 02/12/2018 08:41 AM, Nikolai Kondrashov wrote:
>
>> inner() {
>> unset res
>>
>
> Oh, and duplicating this line fixes the issue.
>
Take a look at these links:
- http://wiki.bash-hackers.org/commands/builtin/unset
-
On Mon, Feb 12, 2018 at 3:23 PM, Nikolai Kondrashov
wrote:
>
>> Take a look at these links:
>>
>> - http://wiki.bash-hackers.org/commands/builtin/unset
>> - http://www.fvue.nl/wiki/Bash:_Passing_variables_by_reference
>>
>
> Thanks, Clark! However, I find it difficult to follow the explanatio
On Sat, Feb 24, 2018 at 11:20 AM, don fong wrote:
>
> i would like to submit this change for inclusion in bash. how should i
> proceed?
>
It's very common to send patches directly to this mailing list. I believe
it's also OK to send only to Chet. :)
On Mon, Feb 26, 2018 at 11:07 PM, Greg Wooledge wrote:
> On Mon, Feb 26, 2018 at 09:57:10AM -0500, Clint Hepner wrote:
> > If necessary, you can define a global (at the expense of a single
> subprocess)
> >
> > myIFS=$(printf ' \t\n')
>
> That actually won't work, because $(...) strips the tr
On Fri, Mar 2, 2018 at 12:37 PM, don fong wrote:
> Chet, thanks. in subst.c there is code that looks similar to what i had
> suggested. but i don't see the tests that i submitted. i also don't see
> the change listed in CHANGES?
>
It's in the file CWRU/CWRU.chlog:
On Sun, Mar 4, 2018 at 5:15 AM, don fong wrote:
> admittedly this is a very minor point, but i am curious. this has to do
> with coding standards for bash source.
>
> consider an if statement in C (or bash, for that matter). which is form is
> better?
>
> Form (A):
>
> if (flag)
> X
On Mon, Mar 5, 2018 at 9:13 AM, don fong wrote:
> Clark, thanks for your answer.
>
> I use ``if (flag)'' only when `flag' is a boolean.
>
>
> but in this case, it *is* a boolean, as i stated, and as can be seen in
> subst.c:
>
> +{
> + if (check_nullness)
> + report_error (_("%s
I don't know much about bash's source code so I cannot comment much. And
this kind of arguments are quite opinion based which are not simple yes/no
questions. And I believe one thing - the world is not perfect. :)
-clark
On Tue, Mar 6, 2018 at 8:26 AM, don fong wrote:
> Clark,
>
> Just took a l
On Sat, Mar 17, 2018 at 1:00 AM, wrote:
>
> It works correctly if the single quote is itself quoted. Our test wordlist
> would then be: "foo\'bar aaa bbb"
>
> paulo@monk:~/tmp$ compgen -W "foo\'bar aaa bbb" -- a
> aaa
> paulo@monk:~/tmp$ compgen -W "foo\'bar aaa bbb" -- b
> bbb
> paulo@monk:~/tmp
On Sat, Mar 17, 2018 at 7:32 PM, Paulo Marcel Coelho Aragão <
marcelpa...@gmail.com> wrote:
> > Actually every word in the -W "wordlist" needs to be sh-quoted twice
> (with
> > ``printf %q'' or the new ``${var@Q}'' syntax). It'll be a bit easier if
> you
> > use an array.
>
> On a second thought,
On Sun, Mar 18, 2018 at 1:18 AM, Chet Ramey wrote:
> On 3/17/18 12:16 AM, Clark Wang wrote:
> > On Sat, Mar 17, 2018 at 1:00 AM, wrote:
> >
> >>
> >> It works correctly if the single quote is itself quoted. Our test
> wordlist
> >> would then be:
On Mon, Mar 19, 2018 at 9:52 PM, Chet Ramey wrote:
> > `-o filenames' would append `/' to a word if the word is coincidentally a
> > real existing dir name. How can I ask it not to append the `/'?
>
> You can't. That's the implication from my second paragraph.
>
OK. I'll stick with my 2-pass sh-
Hi Chet,
Today I compiled bash5 (using default configuration) from the devel branch
(f602026a0ce - commit bash-20180316 snapshot) on macOS and found it breaks
one of my rc files. After some time of debugging I have the following
minimal example to reproduce the problem:
$ bash5 -c 'for i; do echo
On Wed, May 30, 2018 at 8:25 AM, Marty E. Plummer
wrote:
> > If people are willing to do the conversion between patch formats for
> their
> > own purposes, more power to them. I don't see any compelling reason to
> > change the format I use.
> >
> Could I at least convince you to start doing -p1,
On Wed, May 30, 2018 at 7:15 AM, L A Walsh wrote:
> While I certainly don't mind having an option
> to include -_ as case-variations, I don't really like having it
> as a standard or a default
>
I never know there's such a "completion-map-case" option. It is by default
OFF.
On Mon, Jun 4, 2018 at 11:48 AM, Edward Huff wrote:
> That is unexpected.
>
I agree it may look "unexpected" because "cat
On Mon, Jun 11, 2018 at 6:12 PM, Bartłomiej Palmowski
wrote:
>
> The issue is:
> $ cat bad
> (
> set -e
> false
> echo "Shouldn't happen?"
> ) && :
> $ bash ./bad ; echo $?
> Shouldn't happen?
> 0
> $ cat good
> (
> set -e
> false
> echo "Shouldn't happen?"
> )
> $ bash ./
On Wed, Jun 20, 2018 at 10:22 PM, George wrote:
>
> Personally I do think some method of handling arbitrary binary data in the
> shell would be a welcome addition (and I think zsh provides that - don't
> remember if ksh does)
>
Ksh93 has "typeset -b" which defines vars for binary data (actually
On Wed, Nov 8, 2017 at 9:46 PM Chet Ramey wrote:
> On 11/7/17 11:38 PM, Clark Wang wrote:
>
> > I made a patch (also attached). Please see if it's ok.
> >
> >
> > Updated by dealing with empty strings (and malloc'ing 2 more bytes)
> >
Hi Chet,
Just tried 5.0-beta2 and it broke my completion rules. It can be reproduced
with the following steps:
# complete -r
# foo() { true; }
# complete -o default -o bashdefault -D -F foo
# cd /<-- Here it does not list dirs under `/'. Works fine
with 4.4.
Please take a look.
-clark
On Wed, Jan 2, 2019 at 8:38 PM Vladimir Marek
wrote:
> >
> > Thanks, that's good to have confirmed! It was hoping as much -- it would
> > have been hard to believe that something this basic is broken on Solaris
> in
> > general.
>
> Heh :) I am heavy shell scripter/user and I have found multiple
Seems like if there's "complete -D" defined then "progcomp_alias" would
never work. So does it make more sense to make "progcomp_alias" has higher
priority than "complete -D"?
On Tue, Jan 22, 2019 at 1:32 PM Peng Yu
mailto:pengyu...@gmail.com>> wrote:
Hi,
GLOBAL_COMMAND is mentioned as a global variable. But I don't find it.
Is it renamed to something else?
execute_cmd.c
373-
374-/* Execute the command passed in COMMAND. COMMAND is exactly what
375: read_command ()
On Sun, Oct 6, 2019 at 12:17 AM ao2 wrote:
> [...]
>
> Description:
>
> I noticed that when there is a newline in the prompt bash "forgets"
> about ANSI color sequences when the window is resized. I am not
> sure
> f this is general for other kinds of ANSI escape codes.
>
It's quite common for people to press CTRL-C to discard the current command
line. This is harmless actually for most times except when people include
$? in $PS1. I also show $? in red color when it's not 0 so it's more
noticeable. So is it OK to not change $? when people are pressing CTRL-C to
disc
On Fri, Nov 22, 2019 at 12:02 AM Chet Ramey wrote:
>
> This behavior dates from at least 2009 and was added at user request so
> they could tell exactly that: whether or not entering the last command had
> been interrupted by a signal.
>
Curious why people care about this?
-clark
Hi Chet,
On Fri, Nov 22, 2019 at 12:02 AM Chet Ramey wrote:
> On 11/20/19 9:27 PM, Clark Wang wrote:
> > It's quite common for people to press CTRL-C to discard the current
> command
> > line. This is harmless actually for most times except when people include
> >
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-2bxm7h/bash-
5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname ou
See the following example (tested with bash 5.0.7):
# bind -q shell-expand-line
shell-expand-line can be invoked via "\e\C-e".
# echo $PWD # press ESC C-e
# echo /root
# echo $( pwd ) # press ESC C-e
# echo /root
# echo $'foo'# press ESC C-e
# echo $foo
Is this a bug?
-clark
1 - 100 of 295 matches
Mail list logo
