On Sunday, January 13, 2013 04:54:59 PM Chet Ramey wrote:
> On 1/9/13 2:00 PM, Dan Douglas wrote:
> > When expanding simple commands, steps 3 and 4 are reversed unconditionally
> > for
> > all command types and number of words expanded, even in POSIX mode.
> > http://pu
d.h
- W_NOBRACE: new word flag that means to inhibit brace expansion
subst.c
- brace_expand_word_list: suppress brace expansion for words with
W_NOBRACE flag
--
Dan Douglas
mand :; echo survived'
bash: a: readonly variable
survived
$
$ ( n=10 x= POSIXLY_CORRECT=; while printf "${x:-true} "; ((n--)); do x=
${x:-true ${x:=:}}; done )
true : true : true : true : true : true
$ ( n=20 x=: POSIXLY_CORRECT=; while printf %s "${x:--) }"; ((n--)); do x=
${x:-true ${x:=:}}; done )
:-) :-) :-) :-) :-) :-) :-) :-) :-) :-)
--
Dan Douglas
Oops nevermind, I see the issue now. Couldn't reproduce here either. Neither
with compat modes nor the real versions.
--
Dan Douglas
bash 3.x, so I hadn't encountered it). Thanks.
>
> - John
In scripts it breaks POSIX, conflicts with the coproc operator in kshes, and
applies the redirections in an unintuitive order since the same operator
redirects stdout first, then applies the stderr redirect after other
redirections. It isn't very common to dump multiple streams into one pipe. I
suggest avoiding |&.
--
Dan Douglas
On Saturday, January 19, 2013 02:47:38 PM Chet Ramey wrote:
> On 1/18/13 4:10 PM, Dan Douglas wrote:
>
> > In scripts it breaks POSIX, conflicts with the coproc operator in kshes,
> > applies the redirections in an unintuitive order since the same operator
> > redi
t;
Here-strings are of course an exception to the last sentence, and possibly an
exception to parts of the previous sentence (here-strings are defined in terms
of the here-document, which might make the issue not so straightforward).
--
Dan Douglas
three four # bad
var="${a[@]}" ... one:::two three:::four # good
var=$@... one two three four # bad
var="$@" ... one:::two three:::four # good
Zsh and pdkshes produce:
one:::two:three:::four
For all of the above, which I think is wrong for the last 4. ksh93 produces:
one:::two three:::four
for the last 4, which I think is correct.
--
Dan Douglas
On Wednesday, January 30, 2013 02:00:26 AM Chris F.A. Johnson wrote:
> On Wed, 30 Jan 2013, Dan Douglas wrote:
>
> > Hi everyone, and welcome to another edition of IBOTD (IFS-bug-of-the-day),
> > featuring everyone's favorite Bourne shell kludge: word-splitting!
>
On Wednesday, January 30, 2013 11:35:55 AM Chet Ramey wrote:
> On 1/30/13 2:47 AM, Dan Douglas wrote:
>
> > No, $* always expands to a single word. If multiple words result, those
> > are
> > the result of field-splitting, not an intrinsic multi-word expansion as
to a nul
byte. To be completely clear, the command: `read -rd '' x' is literally
receiving the same arguments as the $'\0' case -- it's not only that `read' is
treating them the same.
Also, if it means anything, sadly ksh93 didn't perform that termination
On Sunday, February 24, 2013 02:43:03 PM Chris Down wrote:
> Hi all,
>
> Unless I'm misunderstanding how it should work, `cd -P -e' does not work as
> specified by the documentation. From `help cd':
Yep, see: http://lists.gnu.org/archive/html/bug-bash/2013-01/msg00099.html
--
Dan Douglas
On Sunday, February 24, 2013 10:26:52 PM Thorsten Glaser wrote:
> Dan Douglas dixit:
>
> >Zsh and pdkshes produce:
> >
> >one:::two:three:::four
> >
> >For all of the above, which I think is wrong for the last 4. ksh93
> >produces:
>
> Why is it i
tions of their
> own and then just use those.
>
I agree that's an excellent strategy. :)
--
Dan Douglas
On Friday, March 01, 2013 11:49:37 AM Thorsten Glaser wrote:
> Dan Douglas dixit:
>
> >Well, ok then. I'm just nitpicking here. I think this makes sense because
> >distinguishes between $@ and $* when assigning to a scalar, so that the end
> >result of $@ is alwa
the others can be kept as-is.
>
I think the root of the problem is trying to force unquoted $@ to be like $*
instead of the other way around. That's how bash (if not for the bug) and
ksh93 manage to do this while remaining consistent with the spec.
--
Dan Douglas
( n )); do # end condition
# cmds...
cmd $((n--)) # Hope that there's a convienient spot for $(())
done
}
This construct at least extends the portability to pdksh and probably a few
others. I usually draw the line at shells that lack typeset and inform people
to upgrade to something modern.
--
Dan Douglas
#x27;t have this issue. Dash doesn't actually export the
variable to the environment in this case, but just "localizes" it, and requires
a separate export.)
--
Dan Douglas
ignment, though I can't think of any uses for it.
Arguments in this case are treated neither as ordinary assignments
nor ordinary expansions.
--
Dan Douglas
2>&1; wait $!; printf 2; }
| cat; echo'
12
$ bash -c '{ { : <(sleep 1; printf 1 >&2); } 2>&1; wait $!; printf 2; }
| cat; echo'
bash: wait: pid 9027 is not a child of this shell
21
At least, this is a confusing error, because that actually is a direct child
of the shell that runs the wait. Process substitutions do set $! in Bash, not
in Zsh.
--
Dan Douglas
unexpected token `('
If it's true that an assignment prefix causes bash to not recognize
declaration commands (which is unfortunate IMO), then you would expect the 2nd
case above to be the same as the 3rd case. Instead, it's not wordsplitting and
not failing due to the () metacharacters, and using sort of a hybrid of the
two.
--
Dan Douglas
Can you whittle this down to the smallest reproducer and post a stand-alone
synthetic testcase with sample input data that fails?
If the goal is simulating "exported arrays", there are other methods that
would probably work out better.
--
Dan Douglas
t(1) is an option for those that want --. AFAIK, it's consistent
everywhere it's been implemented. There's a (barebones) example loadable, and
it's quite easy to define a print shiv in shell if needed.
Although, comparing the length:
printf %s
print -rn
It's just as easy to type printf.
--
Dan Douglas
primary advantages to set -A are:
- It's the most portable way to assign multiple elements to an indexed array
other than a separate assignment for each element.
- The combination `set -sA' provides a means of sorting (lexicographically).
Bash currently has no built-in way to sort an array or the positional
parameters.
--
Dan Douglas
tored in the variable x
19:32:51 jilles: freebsd sh and kmk_ash say no, dash says yes
19:33:40 jilles: Bourne shell says no
--
Dan Douglas
pically a symlink to busybox yes, which calls the shell. "jsh" is the
default binary name produced by the heirloom build, though I've seen other
names used.
--
Dan Douglas
On Saturday, April 06, 2013 09:37:44 PM Chet Ramey wrote:
> On 4/6/13 4:48 AM, Dan Douglas wrote:
> > I couldn't find anything obvious in POSIX that implies which
> > interpretation is
> > correct. Assuming it's unspecified.
> >
> > Bash (4.2.45) uniquel
I can't reproduce using the above code.
$ bash ./testcases/substperf
real0m0.000s
user0m0.000s
sys 0m0.000s
real0m0.000s
user 0m0.000s
sys 0m0.000s
As an aside, don't store commands in variables.
http://mywiki.wooledge.org/BashFAQ/050
--
Dan Douglas
On Tuesday, April 09, 2013 10:23:34 PM Chet Ramey wrote:
> On 4/9/13 9:56 PM, Dan Douglas wrote:
> > Erm, here it is in a less unreadable format:
>
> It is pretty slow. You forgot to enable `extglob'.
D'oh!
Bad algorithm? I suppose it's lots of backtracki
ay to handle signals in shell. They don't have to
be complicated.
http://mywiki.wooledge.org/ProcessManagement
http://mywiki.wooledge.org/SignalTrap
--
Dan Douglas
e
behavior of $! was either a nonstandard extension or unintentional bug. Check
the changelog.
--
Dan Douglas
89 2790
dash: empty 2793 2794 2795 2796
zsh: 0 2800 2801 2802 2803
mksh: empty 2807 2809 2810 2811
ksh: empty 2814 2815 2816 2817
posh: empty 2820 2821 2822 2823
bb: empty 2826 2827 2828 2829 # busybox
sh: empty 2832 2833 2834 2835 # bash POSIX mode
--
Dan Douglas
ent contexts. This will yield 0 for initial values of `a' between 1
and 4:
a=2; [[ 0 -ne --a" && "--a && --a -ne 0 ]] && let --a; echo $a
10 factorial (bash/ksh93/zsh):
$ f=n=n?n--*f:1 let n=10 f
$ echo "$n"
3628800
--
Dan Douglas
; DEBUG
$ [ <& $[ ] [ = [ && printf '%s\n' "$_ ...ha :)"
[ [ = [ 0<&$[ ]
[ ...ha :)
I like this. :)
6. Indirection combined with another modifier expands arrays to a single word.
$ a=({a..c}) b=a[@]; printf '<%s> ' "${!b}"; echo; printf '<%s> '
"${!b/%/foo}"; echo
I might have already reported this but can't find it. Ignore if so.
--
Dan Douglas
On Thursday, June 13, 2013 02:54:57 AM Linda Walsh wrote:
> I can't speak to all your cases, but I had comments on a few:
>
> Dan Douglas wrote:
>
> > Most shells (and GCC) consider not grouping the assignment in a situation
> > like this an error. Bash toler
her script, then responsibility for
making that guarantee is inherited by the library consumer. There's no
difference.
To validate a "parameter name" fully requires a full shell parser, because the
subscript of an indexed array is effectively a part of its name as far as Bash
is concerned.
--
Dan Douglas
On Friday, June 14, 2013 06:02:15 AM Dan Douglas wrote:
> On Monday, June 10, 2013 09:39:56 AM Greg Wooledge wrote:
> > > On 10 Jun 2013 14:15, "Chris F.A. Johnson" wrote:
> > > >It is not the least bit difficult with eval:
> > > >
> > >
On Friday, June 14, 2013 02:30:19 PM Pierre Gaston wrote:
> On Fri, Jun 14, 2013 at 2:25 PM, Dan Douglas wrote:
> > Also forgot to mention (though it should be obvious).
> >
> > $ ~/doc/programs/bash43 -c 'function f { typeset -n x=$1; : "$x"; }; a=(yo
while
[[ ${!1+_} ]] || return 1
typeset -a "__getElemArr=${!1}"
set -- "__getElemArr${1#*]}"
[[ $1 == *\[!(@]|\*]) ]]
do :
done
printf '<%s> ' "${!1}"
echo
}
a=( '(a b c)' $'([3]=\'(d e f)\' [5]=1 2 3)' '(g h i)' )
# typeset -a a=(([0]=a [1]=b [2]=c) ([3]=([0]=d [1]=e [2]=f) [5]=1 [6]=2 [7]=3)
([0]=g [1]=h [2]=i) )
getElem 'a[1][3][@]' || echo unset
--
Dan Douglas
expansion do not occur within the [[ keyword.
Where does it say that you can count on [[:alpha:]] being the same in non-POSIX
locales? I see it defined for the POSIX locale.
Thanks to mksh, posh, etc not supporting POSIX character classes at all, I'm
not so sure it's actually better in practice. (talking about standard shell
pattern matching of course)
--
Dan Douglas
On Thu, Jun 20, 2013 at 7:09 AM, Greg Wooledge wrote:
> On Wed, Jun 19, 2013 at 06:12:57PM -0500, Dan Douglas wrote:
>> Thanks to mksh, posh, etc not supporting POSIX character classes at all, I'm
>> not so sure it's actually better in practice. (talking about standard
This function (colorSet) takes one or more associative array names and
can populate it with a few predefined color palates. Written for
Bash/ksh93/zsh.
http://wiki.bash-hackers.org/snipplets/add_color_to_your_scripts
--
Dan Douglas
l text color.
>
> You can get around that by using read:
>
>
> read _CRST < <(tput sgr0) #Reset
> read _CRed < <(tput setaf 1) #Red
> read _CBLD < <(tput bold) #Bold
Can also give all the debug output %q formatting.
exec {BASH_XTRACEFD}> >(set +x; while IFS= read -r x; do printf %q\\n "$x";
done)
--
Dan Douglas
assigning the
values, which is why:
$ ( declare -ia foo=(1 2 xx 3); echo "${foo[@]}" )
1 2 xx 3
always gives you the xx, while forcing the evaluation to be done within
declare's environment gives a different result (e.g. with quotes):
$ ( declare -ia 'foo=(1 2 xx 3)'; echo "${foo[@]}" )
1 2 0 3
I think this was already known and not a bug, and doesn't have to do with the
order options are supplied in.
--
Dan Douglas
about this here over a year ago:
http://wiki.bash-hackers.org/syntax/arrays#integer_arrays
I think I even have some code that relies upon this effect.
--
Dan Douglas
quot; is still going to end up evaluating to whatever expression is stored in x.
If you want, you can force it to behave the other way as shown in my first
reply.
The primary reason I said it isn't a bug is because this has been discussed on
the list a few times before and that's been the general consensus.
--
Dan Douglas
become string assignments.
Same.
> 6. Indirection combined with another modifier expands arrays to a single
> word.
fixed.
:-)
--
Dan Douglas
ests should run in any shell provided
# you can supply all the necessary workarounds, and they correctly interpret
# ksh93 printf %q output (requires $'...'). At least one level of recursive
# arithmetic variable evaluation must also be supported.
# Dan Douglas
namespace main {
nsequenced]
int main() { int x=0; printf("%d\n", x+=x=1); return 0; }
~~ ^
1 warning generated.
2
--
Dan Douglas
On Sunday, August 04, 2013 12:30:48 AM Roland Mainz wrote:
> On Sun, Aug 4, 2013 at 12:04 AM, Dan Douglas wrote:
> > Is it specified what the value of x should be after this expression?
> >
> > x=0; : $((x+=x=1))
> >
> > Bash, ksh93, mksh, posh say 1. zsh, d
value}
((i = .sh.value))
}
((x[a] += x[b] = 1))
print result: $i
--
Dan Douglas
h variable,
the RHS fires before the LHS of the +=.
There's just no amount of mind-bending I can think of that could make
evaluating the += first produce anything other than an error.
--
Dan Douglas
RSION"
> 4.2.45(2)-release
>
> It also occurs in 4.2.45(1)-release and 3.2.51(1)-release.
This was this issue:
http://gnu-bash.2382.n7.nabble.com/More-fun-with-IFS-td11388.html
The assignments are all consistent in 4.3.
https://gist.github.com/ormaaj/6381747
--
Dan Douglas
-o and -a are for entertainment.
~ $ bash -c 'set -a; [ -o -a -o -a -o ]; echo $?'
1
~ $ mksh -c 'set -a; [ -o -a -o -a -o ]; echo $?'
0
~ $ bash -c '[ -o -a -o -a > -o -o ]; echo $?'
0
~ $ mksh -c 'o=1 [ -o -a -o -a -gt -o ]; echo $?'
0
--
Dan Douglas
POSIX mode. I don't have a strong
desire for this. A good editor should make normal comments painless enough.
--
Dan Douglas
On Saturday, April 06, 2013 03:48:55 AM Dan Douglas wrote:
> Bash (4.2.45) uniquely does interpret such escapes for [[, which makes me
> think this test should say "no":
>
> x=\\x; if [[ x == $x ]]; then echo yes; else echo no; fi
>
Here's more data. Some perm
On Monday, October 07, 2013 10:21:06 AM Chet Ramey wrote:
> The subshell command is clearly part of the || compound command. The
> subshell `knows' that it is part of || and set -e has no effect. This
> example has been discussed before, on this list and the austin-group
> Posix list, and the bas
s exit='eval "$BASH_COMMAND"'
$ alias shutdown='eval $BASH_COMMAND\&{,}'
--
Dan Douglas
#x27;s the patch?
>>
>> Just to be sure, this does use the extended attributes with O_XATTR, right?
>
> Yes, Cedric's patch uses O_XATTR.
Mhhh.
That would be very useful to have, at least much better than the
cranky runat(1) kludge.
Is there a branch I can checkout to try?
Dan
hem.
>>>
>>> Chet, can you push the patch to git to avoid that other people stumble
>>> over that build issue, please?
>>
>> I pushed another snapshot this morning.
>
> Thank you. Seems to work fine :)
>
> Ced
> --
> Cedric Blancher
> Institute Pasteur
>
Seems to be working OK in bash4.3 rc1, too.
Chet, Cedric, thank you!
Dan
On Fri, Jan 17, 2014 at 8:07 AM, Greg Wooledge wrote:
> On Fri, Jan 17, 2014 at 08:53:07AM -0500, Chet Ramey wrote:
>> On 1/17/14 8:01 AM, Greg Wooledge wrote:
>> > I would expect [[ x =~ yx ]] to fail (return 1) every time.
>>
>> There is a question about the correct behavior when y == '\', since
Thanks fellows but now bash has become very slow to the touch that way.
Can you somehow give the user his prompt first and then wait, instead of
the other way around? Also rapid ^P RET ^P RET should somehow be exempt.
> "PG" == Pierre Gaston writes:
PG> Maybe try something like: PROMPT_COMMAND='read -t0 && sleep 10'
But how will that on its own stop me from dumping tons of lines of junk
into bash via one accidental mouse click?
Ah ha! Thanks for the private tip 4 minutes ago. This works!:
saftey_seconds=5
PROMPT_COMMAND='if ((SECONDS==0)); then echo TOO FAST HOLMES, waiting '\
$saftey_seconds' seconds or hit ^C; sleep '$saftey_seconds'; else SECONDS=0; fi'
Hope somebody documents it somewhere as otherwise, well, "the sh
case $- in *i*)
saftey_seconds=5 SECONDS=1
PROMPT_COMMAND="if ((SECONDS==0)); then echo TOO FAST HOLMES, waiting \
$saftey_seconds seconds or hit ^C; sleep $saftey_seconds; else SECONDS=0; fi"
esac
OK fixed spelling.
Put in .bashrc to prevent accidental execution of many line clipboard paste
dumps:
case $- in *i*)
safety_seconds=5 SECONDS=1
PROMPT_COMMAND="if ((SECONDS==0)); then echo TOO FAST HOLMES, waiting \
$safety_seconds seconds or hit ^C; sleep $saftey_seconds; else SEC
# su - nobody
No directory, logging in with HOME=/
$ cat /tmp/r
LC_CTYPE=zh_TW.UTF-8 N=$(echo 統一|iconv -t big5 -f utf-8) sh -xc ': $N'
$ sh /tmp/r
/tmp/r: line 1: 4551 Segmentation fault LC_CTYPE=zh_TW.UTF-8 N=$(echo
統一|iconv -t big5 -f utf-8) sh -xc ': $N'
Something about that embedded nul
What a clod I was, thinking @ was ^@.
OK glad you guys are hot on the trail.
Dear Bug-Bash gentlemen,
http://debbugs.gnu.org/16665 says it seems like a bash bug.
Please have a look if you are also an emacs person.
> "CR" == Chet Ramey writes:
CR> OK, I'll bite. What is C-c C-c supposed to do? It looks like it just
CR> spews a bunch of garbage to your screen. Is that the intent?
C-c C-c runs the command comint-interrupt-subjob, which is an
interactive compiled Lisp function in `comint.el'.
(comint-
Try
su - nobody #(pristine account)
then type :
then type ESC . ESC .
Whammo! The shell dies!
The second ESC . acts like ^D.
# su - nobody
No directory, logging in with HOME=/
nobody@jidanni5:/$ cd /tmp
nobody@jidanni5:/tmp$ script
Script started, file is typescript
nobody@jidanni5:/tmp$ :
nobody
Hitting TAB twice at the end of
nobody@jidanni5:/$ : /home/jidanni/jidanni.org/location/directions/
nobody@jidanni5:/$ : ~jidanni/jidanni.org/location/directions/
shows a list of list of the filenames for the former, but not the
latter. Indeed the for the latter one will have to type the filenames
X-debbugs-cc: chet.ra...@case.edu bug-bash@gnu.org
Package: bash-completion
Version: 1:2.1-2
>>>>> "CR" == Chet Ramey writes:
CR> On 2/21/14, 9:33 PM, Dan Jacobson wrote:
>> Hitting TAB twice at the end of
>> nobody@jidanni5:/$ : /home/jidanni/jidanni.org
On Fri, Mar 7, 2014 at 1:38 PM, Eduardo A. Bustamante López
wrote:
> WARNING: the codes given below cause the shell to enter an infinite
> loop.
>
>
> Both:
> dualbus@debian:~$ bash -Tc 'f(){ :; }; trap return RETURN; f'
> ^C
>
> and:
> dualbus@debian:~$ bash -c 'f(){ trap return RETURN; }; f'
> ^
" syntax. IMO it shouldn't even be
documented. It causes endless confusion but the reason it exists isn't clear.
There are other alternate syntaxes that are also discouraged, but undocumented,
such as the "for ((;;)) { ...; }" syntax.
--
Dan Douglas
#x27;t
care to make every script depend on it.
The -a/-A problem is definitely the most common and annoying of these though
and the -A would be very useful even if left undocumented or marked as
deprecated.
--
Dan Douglas
On Thu, Mar 27, 2014 at 3:16 AM, Dan Douglas wrote:
> I have such a function of course, but don't care to make every script depend
> on it.
Oh, and of course I'll still be using the wrapper. This is a feature for my
great grandchildren to use once Apple is out of business and the
I don't believe any shell can currently read nul-delimited input into
an array without looping. It's been suggested to add a delimiter to
mapfile. It looks like mapfile uses zgetline() to wrap around calls to
zread() and doesn't support any delimiter. read(1) on the other hand
uses one of the zread
On Thu, Mar 27, 2014 at 5:05 PM, Mike Frysinger wrote:
> thanks, i wasn't aware of that func. that seems like the easiest solution.
mapfile it awesome, but for getting find(1) results into an array you
should continue to use a read -rd '' loop. read -d is somewhat
portable, and mapfile does not
atures such as "read
-N" do, and most work directly involving the shell is with text not binary data.
--
Dan Douglas
Not sure we have enough info here. Have you tried "set -x" to see what's really
going on? Have you also confirmed that it isn't actually calling your script
and the script simply isn't functioning as expected?
--
Dan Douglas
;evil here"; }; dequote() { eval printf %s "$1" 2> /dev/null;
}; set -x; dequote "; evil" )
+ dequote '; evil'
+ eval printf %s '; evil'
evil here
--
Dan Douglas
ub.com/ormaaj/04923e11e8bdc27688ad#file-output
As you can see there isn't much rhyme or reason to the results, and
these tests take into account all the other differences that don't have
to do with exporting.
Test 1 exports a global then localizes it. Test 2 exports a local and
tests a local from a child scope. Test 3 tests exported namerefs.
--
Dan Douglas
h -c 'printf "<%.010d> <%.*d>\n" 1 010 1'
<000001> <01>
(...and if everybody else follows suit, they won't be missed. Worked out
fine for ECMAScript5 strict.)
--
Dan Douglas
On Monday, May 05, 2014 09:37:27 AM Eric Blake wrote:
> On 05/05/2014 05:09 AM, Dan Douglas wrote:
> > Just a heads up on something I hadn't noticed: Bash (and dash) treat
> > octal literals in printf precision inconsistently (using glibc -- not
> > sure if it's a b
ized x in g should hide f's x even with no value.
function f { typeset x=set; g x; }
function g { typeset x; h x; }
function h { typeset -n ref=$1; echo "${ref-unset}"; }
f x # should print "unset"
--
Dan Douglas
"; echo "$y"
+ typeset -n x
+ x='_; y'
+ x=foo
+ typeset -p '_; y'
declare -- _; y="foo"
++ typeset -p '_; y'
+ eval 'declare -- _; y="foo"'
++ declare -- _
++ y=foo
+ echo foo
foo
--
Dan Douglas
73bd08 "function f {
typeset x; typeset -n x; x=y; }; f",
from_file=0x4dcc50 "-c", flags=4) at evalstring.c:367
#21 0x0041f6ee in run_one_command (command=0x7fffd5fe "function f {
typeset x; typeset -n x; x=y; }; f") at shell.c:1339
#22 0x0041e9e0 in main (argc=3, argv=0x7fffd108,
env=0x7fffd128) at shell.c:694
--
Dan Douglas
On Wednesday, May 07, 2014 10:04:11 AM Chet Ramey wrote:
> On 5/7/14, 2:10 AM, Dan Douglas wrote:
> > By "doesn't shadow" you mean that it _does_ hide the global right?
> > Localizing
> > a variable should cover up globals and variables in parent scopes even i
On Wednesday, May 07, 2014 10:58:42 AM Chet Ramey wrote:
> On 5/7/14, 10:21 AM, Dan Douglas wrote:
> > Another one to do with namerefs. :-)
> >
> > Looks like it's when the target of the ref is local to the same scope.
> >
> > $ gdb -q -ex 'run -c "
40513 20140514 20140515 20140516 20140517
20140518 20140519
$ ksh -c 'printf "%(%Y%m%d)T " "" -{1..9}\ days; echo'
20140510 20140511 20140512 20140513 20140514 20140515 20140516 20140517
20140518 20140519
--
Dan Douglas
On Saturday, May 10, 2014 03:31:05 PM Dan Douglas wrote:
> $ bash -c 'printf -v a "%(%s)T" -1; printf "%(%Y%m%d)T " "$a"
"${a[a+=60*60*24,0]"{0..8}"}"; echo'
> 20140510 20140511 20140512 20140513 20140514 20140515 2014
usage of
GNU factor(1) (or at least the silliest).
http://wiki.bash-hackers.org/syntax/expansion/brace#more_fun
--
Dan Douglas
uot; that programmers can't not depend on.
I disagree with Guido, as do many others. Though all the same arguments apply
in this case. I see no good reason for an arbitrary limit but I understand the
opposing view.
--
Dan Douglas
0m0.035s
user0m0.020s
sys 0m0.033s
$ time bash -c 'f() { echo "$1"; f $(($1 + 1)); }; f 0' | tail -n 1
8308
real0m3.993s
user0m4.032s
sys 0m0.165s
--
Dan Douglas
bug
in ksh here.
# Bash is correct here AFAICT.
$ bash -c 'typeset -A a; i="\$(echo \\\")" a[\"]=1+1; echo "$((a[$i]))"'
2
# ksh93 fails this test:
$ ksh -c 'typeset -A a; i="\$(echo \\\")" a[\"]=1+1; echo "$((a[$i]))"'
ksh: syntax error at line 1: `end of file' unexpected
--
Dan Douglas
On Mon, Jun 9, 2014 at 7:51 PM, Dale R. Worley wrote:
> But if I add braces around the condition, 'time' is recognized:
That's not too surprising. That "!" is unaffected is. "if ! ! time :;
then ..." is an equivalent but working pipeline. "if time { :; };"
should also be valid but time isn't reco
On Tue, Jun 10, 2014 at 8:39 AM, Dale R. Worley wrote:
>> From: Dan Douglas
>>
>> On Mon, Jun 9, 2014 at 7:51 PM, Dale R. Worley wrote:
>> > But if I add braces around the condition, 'time' is recognized:
>>
>> That's not too surprisi
I've heard process substitutions considerably complicate parsing. zsh
and ksh93 are the only others that have process substitutions that I
know of, and zsh can't handle unbalanced parentheses in that situation
either.
$ zsh -c $'cat <(cat <<"EOF"\n(test)(foo\nEOF\n)'
zsh:4: parse error near `<(ca
101 - 200 of 471 matches
Mail list logo
