Configuration Information :
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -D$
uname output: Linux ubuntu 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5
17:45:18 UTC 2012 i6$
Machine Type: i686-pc-linux-gnu
Bash Versi
On Fri, Jan 11, 2013 at 10:21:55PM +0800, Ma Shimiao wrote:
> I used commands as follows:
> $seq 5 | mapfile -C echo -c1
> 0 1
>
> 1 2
>
> 2 3
>
> 3 4
>
> 4 5
>
> I would have expectd 1,2,3,4,5 above from the"help mapfile".
> Is it a bug of mapfile?
The help says:
When CALLBACK is evalu
Thank Greg for your answer very much.
This problem has confused me for 2 days. That seems I didn't read the
manpage carefully.
On 01/11/2013 10:54 PM, Greg Wooledge wrote:
On Fri, Jan 11, 2013 at 10:21:55PM +0800, Ma Shimiao wrote:
I used commands as follows:
$seq 5 | mapfile -C echo -c1
0 1
Whether or not this type of error aborts depends upon there being an actual
newline.
$ bash -c 'echo pre; foo=$((8#9)); echo post' 2>&1
pre
bash: 8#9: value too great for base (error token is "8#9")
$ bash -c $'echo pre\nfoo=$((8#9))\necho post' 2>&1
pre
bash: line 1: 8#9
Bash treats the variable as essentially undefined until given at least an
empty value.
$ bash -c 'typeset -i x; [[ -v x ]]; echo "$?, ${x+foo}"; typeset -p x'
1,
bash: line 0: typeset: x: not found
$ ksh -c 'typeset -i x; [[ -v x ]]; echo "$?, ${x+foo}"; typeset -p x'
0,
t
$ set --; printf %q\\n "$@"
''
printf should perhaps only output '' when there is actually a corresponding
empty argument, else eval "$(printf %q ...)" and similar may give different
results than expected. Other shells don't output '', even mksh's ${var@Q}
expansion. Zsh's ${(q)var} does
Am 11.01.2013 19:38, schrieb Dan Douglas:
> $ set --; printf %q\\n "$@"
> ''
>
> printf should perhaps only output '' when there is actually a corresponding
> empty argument, else eval "$(printf %q ...)" and similar may give different
> results than expected. Other shells don't output '',
Am 11.01.2013 19:27, schrieb Dan Douglas:
> Bash treats the variable as essentially undefined until given at least an
> empty value.
>
> $ bash -c 'typeset -i x; [[ -v x ]]; echo "$?, ${x+foo}"; typeset -p x'
> 1,
> bash: line 0: typeset: x: not found
> $ ksh -c 'typeset -i x; [[ -
On Friday, January 11, 2013 09:39:00 PM John Kearney wrote:
> Am 11.01.2013 19:38, schrieb Dan Douglas:
> > $ set --; printf %q\\n "$@"
> > ''
> >
> > printf should perhaps only output '' when there is actually a
corresponding
> > empty argument, else eval "$(printf %q ...)" and similar ma
shopt -s checkwinsize only works in interactive shells. However, this
is not mentioned in the manual.
Tested in Bash 4.2.37.
#!/bin/bash
trap 'echo "COLUMNS is now <$COLUMNS>"' WINCH
test -z "$COLUMNS" && COLUMNS=$(tput cols)
shopt -s checkwinsize
while sleep 1; do :; done
Run in a terminal, re
On Friday, January 11, 2013 09:48:32 PM John Kearney wrote:
> Am 11.01.2013 19:27, schrieb Dan Douglas:
> > Bash treats the variable as essentially undefined until given at least an
> > empty value.
> >
> > $ bash -c 'typeset -i x; [[ -v x ]]; echo "$?, ${x+foo}"; typeset -p x'
> > 1,
> >
On 1/11/13 4:05 PM, Dan Douglas wrote:
>
> I don't understand what you mean. The issue I'm speaking of is that printf %q
> produces a quoted empty string both when given no args and when given one
> empty arg. A quoted "$@" with no positional parameters present expands to
> zero
> words (and
On 1/11/13 4:13 PM, Greg Wooledge wrote:
> shopt -s checkwinsize only works in interactive shells. However, this
> is not mentioned in the manual.
Yes, that's true. This was reported in June, and the development versions
since then have been changed to make it work in non-interactive shells
as w
On Fri, Jan 11, 2013 at 4:43 PM, Chet Ramey wrote:
> On 1/11/13 4:13 PM, Greg Wooledge wrote:
> > shopt -s checkwinsize only works in interactive shells. However, this
> > is not mentioned in the manual.
>
> Yes, that's true. This was reported in June, and the development versions
> since then
On Friday, January 11, 2013 04:37:56 PM Chet Ramey wrote:
> On 1/11/13 4:05 PM, Dan Douglas wrote:
>
> >
> > I don't understand what you mean. The issue I'm speaking of is that printf
> > %q
> > produces a quoted empty string both when given no args and when given one
> > empty arg. A quoted "
On 1/11/13 4:46 PM, DJ Mills wrote:
> Will they still be updated on WINCH without checkwinsize, as well? And will
> they be set by default, or continue to be unset in scripts unless set
> manually?
The only thing that's changed is that checkwinsize works in non-interactive
shells. SIGWINCH stil
On Fri, Jan 11, 2013 at 4:51 PM, Chet Ramey wrote:
> On 1/11/13 4:46 PM, DJ Mills wrote:
>
> > Will they still be updated on WINCH without checkwinsize, as well? And
> will
> > they be set by default, or continue to be unset in scripts unless set
> manually?
>
> The only thing that's changed is t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 1/11/13 1:27 PM, Dan Douglas wrote:
> Bash treats the variable as essentially undefined until given at least an
> empty value.
This is what Posix says:
A variable is a parameter denoted by a name.
A parameter is set if it has an
On 1/11/13 4:58 PM, DJ Mills wrote:
> As of right now, WINCH will not update COLUMNS or LINES in a
> non-interactive shell.
>
> I've had to use:
> trap 'COLUMNS=$(tput cols); LINES=$(tput lines)' WINCH
> to get that behavior.
And that hasn't changed. Maybe I should look at changing it.
Chet
Am 11.01.2013 22:05, schrieb Dan Douglas:
> On Friday, January 11, 2013 09:39:00 PM John Kearney wrote:
>> Am 11.01.2013 19:38, schrieb Dan Douglas:
>>> $ set --; printf %q\\n "$@"
>>> ''
>>>
>>> printf should perhaps only output '' when there is actually a
> corresponding
>>> empty argume
Am 11.01.2013 22:34, schrieb Dan Douglas:
> On Friday, January 11, 2013 09:48:32 PM John Kearney wrote:
>> Am 11.01.2013 19:27, schrieb Dan Douglas:
>>> Bash treats the variable as essentially undefined until given at least an
>>> empty value.
>>>
>>> $ bash -c 'typeset -i x; [[ -v x ]]; echo
On Saturday, January 12, 2013 02:35:34 AM John Kearney wrote:
> so there is always at least one word or one arg, just because its "${@}"
> should not affect this behavior.
...
> printf "%q" "${@}"
> becomes
> printf "%q" ""
>
> which is correct as ''
No, "${@}" doesn't always become at least one
22 matches
Mail list logo
