Configuration Information:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -
Inside an empty directory:
touch 1 1\'1
complete -r ls
ls 1\' # ls 1\'1
complete -f ls
ls 1\' # ls 1
ls 1\\\' # ls 1\'1
(Note: the comment on the right is the result after pressing )
Is this broken behavior?
Why on earth does the user have to double-escape at all?
Is
(Sorry, forgot to CC the ML.)
On Sat, Oct 15, 2011 at 1:30 AM, Chet Ramey wrote:
> Thanks for the report. This looks like a problem, or an omission, with
> the effects of the `-f' option to complete, since it works as expected
> without using programmable completion or when using `-o default'.
On Sat, Oct 15, 2011 at 1:30 AM, Chet Ramey wrote:
> On 10/13/11 10:37 AM, lolilolicon wrote:
>> Inside an empty directory:
>>
>> touch 1 1\'1
>> complete -r ls
>> ls 1\' # ls 1\'1
>> complete -f ls
>> ls 1\' #
On Sat, Oct 15, 2011 at 10:34 PM, lolilolicon wrote:
>
>
> #!/bin/bash
>
> shopt -s progcomp
>
> mkdir -p 1\'1 2@2
> touch 1\'1/one 2@2/two
>
> for i in \
> "1'1" "1\'1" "1'1/" "1\'1/"
On Sun, Oct 16, 2011 at 9:52 AM, Chet Ramey wrote:
> On 10/15/11 10:34 AM, lolilolicon wrote:
>>
>> OK, some more strange test results.
>>
>> In the interactive bash shell, I did this (in an empty directory):
>>
>> $ mkdir 1\'1 $ mkdir 2@
On Sun, Oct 16, 2011 at 10:52 PM, lolilolicon wrote:
> -- snip --
> I hope the above will help clarify what bash currently does, and how it's
> a bit crazy. I hope to discuss the correct behavior in each case later.
>
Below is the sane behavior I'd like to propose:
Ins
On Wed, Jul 23, 2014 at 9:58 PM, Eric Blake wrote:
>
> Might be worth asking the POSIX folks if it is allowed by POSIX. What
> do other shells do?
>From this page: http://pubs.opengroup.org/onlinepubs/7908799/xcu/chap2.html
Note that the tildes are expanded during the assignment to PATH, no
On Wed, Jul 23, 2014 at 10:43 PM, Eric Blake wrote:
> But we are talking about the case where ~ IS quoted during
> the assignment, and only bash then re-expands it during path lookup.
That's my point. Let me try quoting this again,
Note that the tildes are expanded during the assignment to P
On Wed, Jul 23, 2014 at 11:00 PM, lolilolicon wrote:
> On Wed, Jul 23, 2014 at 10:43 PM, Eric Blake wrote:
>> But we are talking about the case where ~ IS quoted during
>> the assignment, and only bash then re-expands it during path lookup.
>
> That's my point. Let
Sorry for the unhelpful title, but I can't find a one that isn't
longer than the body of the mail.
The following code segfaults when run by bash 4.3.022
set -E
shopt -s lastpipe
trap -- 'true' ERR
true | { true | false; }
This is probably related to the bug patched by bash43-022.
On Mon, Aug 25, 2014 at 8:04 PM, Greg Wooledge wrote:
> On Sun, Aug 24, 2014 at 01:36:38PM +0200, Tim Friske wrote:
>> I currently emulate the behavior I seek for with the following function:
>>
>> function _import {
>> local -r file="$1"
>> set -- "${@:2}"
>> source "$file" "$@"
>> }
>
> Ho
The following is my test scripts and their output.
They are very similar, and I do not think they should result in
different output.
The output I expected from all of them is:
v1
v2
But as you can see, only 1 in the following 4 cases does it meet my
expectation. In the other 3 cases, the nameref
On Sat, Aug 30, 2014 at 11:19 AM, lolilolicon wrote:
> The following is my test scripts and their output.
> They are very similar, and I do not think they should result in
> different output.
> The output I expected from all of them is:
>
> v1
> v2
>
> But as you can s
On Sat, Aug 30, 2014 at 11:39 AM, lolilolicon wrote:
>
> As you see, once ref is assigned explicitly, or indeed, is assigned for
> a second time, its nameref attribute is lost.
OK, here is the minimum script that demonstrates the bug:
=== script ===
#!/bin/bash
declare var="hello
On Sat, Aug 30, 2014 at 11:51 AM, lolilolicon wrote:
> On Sat, Aug 30, 2014 at 11:39 AM, lolilolicon wrote:
>>
>> As you see, once ref is assigned explicitly, or indeed, is assigned for
>> a second time, its nameref attribute is lost.
>
> OK, here is the minimum scrip
Assignment to a subscripted array variable behaves differently for
nameref vs `printf -v`, as shown below.
Assignment via nameref variable:
declare -a arr=()
func() {
local -n ref=$1
ref='nameref'
}
func 'arr[0]'
declare -p 'arr[0]' arr
--- output ---
declare -- arr[0]="nameref"
declare -a a
On Sun, Aug 31, 2014 at 12:20 PM, lolilolicon wrote:
> Assignment to a subscripted array variable behaves differently for
> nameref vs `printf -v`, as shown below.
>
> Assignment via nameref variable:
>
> declare -a arr=()
> func() {
> local -n ref=$1
> ref=
On Sun, Aug 31, 2014 at 12:20 PM, lolilolicon wrote:
> Assignment to a subscripted array variable behaves differently for
> nameref vs `printf -v`, as shown below.
>
> Assignment via nameref variable:
>
> declare -a arr=()
> func() {
> local -n ref=$1
> ref=
On Tue, Sep 2, 2014 at 9:02 AM, Chet Ramey wrote:
> It's a bug that results in `arr[0]' being created as a shell variable.
> I've attached a patch for people who want to experiment with it.
I applied it against 4.3.24 but it failed to build... Am I missing some
patch in between?
variables.c:2560
On Tue, Sep 2, 2014 at 8:59 PM, Greg Wooledge wrote:
> On Sat, Aug 30, 2014 at 12:02:33PM +0800, lolilolicon wrote:
>> > #!/bin/bash
>> > declare var="hello world"
>> > declare -n ref
>> > ref=var
>> > echo $ref
>> > ref=va
variable naming
conventions to avoid such bugs; for instance, I have written a
reminder for my own script,
https://github.com/lolilolicon/FFcast/blob/master/HACKING.markdown
In the `declare -p` output, I mean:
% bash -c 'declare -A x; x=([foo]=bar [x]=y); declare -p x;'
declare -A x='([foo]="bar" [x]="y" )'
Does it serve any purpose? Just curious.
Obviously, the newly disclosed CVE-2014-6271 is pretty bad.
It's been patched now, but I think it's worthwhile to further discuss
how exported functions are implemented in bash.
I'm no bash expert: before today I didn't even realize bash functions
can be exported. And I certainly wouldn't expect
I think almost as severe as CVE-2014-6271 is that it's still possible to
mask commands in a bash script by changing it's environment.
For example, true='() { false;}' or grep='() { /bin/id;}' ...
On Thu, Sep 25, 2014 at 3:53 AM, Greg Wooledge wrote:
> On Thu, Sep 25, 2014 at 03:44:23AM +0800, lolilolicon wrote:
>> Otherwise, if this feature is going to stay (can anyone enlighten me why
>> it's useful?), please document it explicitly.
>
> First, it is documented:
On Thu, Sep 25, 2014 at 9:35 AM, Chet Ramey wrote:
> On 9/24/14, 3:44 PM, lolilolicon wrote:
>
>> Personally, I have never needed this feature. I would vote for its
>> removal: It's very surprising, creates bugs, and is not very useful.
>
> There are more things
On Thu, Sep 25, 2014 at 7:19 AM, Linda Walsh wrote:
> lolilolicon wrote:
>>
>> I don't expect more than a dozen who rely on this... but bash
>> programmers can be quite the perverts, so...
>>
>
> Personally I find those who don't read the man page, and t
On Thu, Sep 25, 2014 at 5:51 PM, Pierre Gaston wrote:
>
>
> On Thu, Sep 25, 2014 at 12:42 PM, lolilolicon wrote:
>>
>> On Thu, Sep 25, 2014 at 7:19 AM, Linda Walsh wrote:
>> > lolilolicon wrote:
>> >>
>> >> I don't expect more than a
On Thu, Sep 25, 2014 at 6:09 PM, Pierre Gaston wrote:
>> In any event, this is but irrelevant to the discussion. Do not seize the
>> red herring.
>
>
> It is fully relevant when you use a sexist stereotype as an argument.
No, I didn't use a sexist stereotype "as an argument". Remove that
sentence
On Thu, Sep 25, 2014 at 9:00 PM, Chet Ramey wrote:
> Even if you use it as a rhetorical device, it distracts from (and detracts
> from) your argument. It doesn't improve the quality of the discussion, so
> it's best not to use it.
Agreed. People can take light-hearted side remarks too seriously.
On Fri, Sep 26, 2014 at 2:28 AM, Ángel González wrote:
[...]
> On the other hand, this approach would be much more interesting if bash
> delayed parsing of exported functions until they are used (ie. check
This is what function autoload is for in zsh. It's indeed a better
approach. It was also su
On Fri, Sep 26, 2014 at 2:53 AM, Linda Walsh wrote:
> ---
> "prevert" _might_ have been more obviously seen as applicable to a bash
> programmer who is "pre-bent" or "pre-twisted" from having programmed in
> shell for so long, compared to the nick, lilololicon, with its 'H'y (as in
> 'Hentai'-y)
On Fri, Sep 26, 2014 at 6:08 AM, Linda Walsh wrote:
>
>
> Eric Blake wrote:
>>
>> Where I'm coming from is that in portable shell programming, you _can't_
>> assign a value to f()=... The fact that portable
>> programs are now "slammed"[sic] with the notion that some values cannot be
>> portably
On Fri, Sep 26, 2014 at 3:24 PM, Vincent Lefevre wrote:
> On 2014-09-25 03:54:19 +0800, lolilolicon wrote:
>> [...] that it's still possible to
>> mask commands in a bash script by changing it's environment.
>>
>> For example, true='() { false;}' o
On Sat, Oct 15, 2016 at 5:41 PM, lolilolicon wrote:
>
> pop() {
> local -n _a=$1
> printf -v "$2" "${_a[-1]}"
and of course I meant
printf -v "$2" '%s' "${_a[-1]}"
The keyword is nameref if you haven't heard of it, so you can look it
up in the man page :)
On Sat, Oct 15, 2016 at 11:12 AM, Marco Ippolito wrote:
> Bash has elegant and powerful constructs like `mapfile',
> yet it is missing something as easy as an array "pop".
>
> Extract the last value of an array at the same time as
> removing it from the array.
>
> Is this the best one can do?
>
>
On Sat, Oct 15, 2016 at 7:45 PM, Marco Ippolito wrote:
> On Sat, Oct 15, 2016 at 05:41:32PM +0800, lolilolicon wrote:
>> pop() {
>> local -n _a=$1
>> printf -v "$2" "${_a[-1]}"
>> unset _a[-1]
>> }
>>
>> declare -a a=(a
On Sat, Oct 15, 2016 at 10:50 PM, konsolebox wrote:
>
> My version would be this:
>
> function array_pop { declare -n __a=$1 __v=$2; __v=${__a[-1]}; unset
> '__a[-1]'; }
>
Here's another version which avoids local or nameref variables,
pop() {
[[ -v $1 ]] || return
set -- "$1[-1]" "$2"
On Mon, Oct 17, 2016 at 6:01 AM, isabella parakiss wrote:
>
> f() { TIMEFORMAT=f; time :; }
> time ( f )
> f
> f
>
> setting TIMEFORMAT in ( ) affects time out of the subshell
> this cannot be right
time is a reserved word, not a builtin. time is not "out of the
subshell". Its env is that of the
The following correctly prints "fd=2":
coproc p { head -1; }
2>&${p[1]} bash -c 'echo fd=2 >&2'
cat <&${p[0]}
Change 2 to 3, throws error: "bash: 3: Bad file descriptor":
coproc p { head -1; }
3>&${p[1]} bash -c 'echo fd=3 >&3'
cat <&${p[0]}
I'm not very familiar with re
On Thu, Oct 20, 2016 at 11:32 PM, Martijn Dekker wrote:
> #! /usr/local/bin/bash
> insubshell() {
> return "$((BASHPID=$$))"
> # ^ fatal typo
> }
> for ((i=0; i<1; i++)); do insubshell; done
> echo $i
> insubshell || echo ok
> echo continuing
>
> The output of t
On Fri, Oct 21, 2016 at 1:31 AM, lolilolicon wrote:
> bash simply aborts this command.
I think I mean "list".
43 matches
Mail list logo
