Re: Unexpected word splitting on $* when IFS is unset

2017-06-24 Thread Eduardo A . Bustamante López
On Sat, Jun 24, 2017 at 09:35:34AM +0700, Robert Elz wrote: [...] > In cases where IFS is not a null string, the broken implementations mostly > tend to work OK (sometimes perhaps only by a fluke), and even more work > properly if IFS has its default value or something similar, that is > where IFS[

Bug in select-command

2017-06-24 Thread sky...@top-email.net
It is necessary to refresh the variable $COLUMNS in a script (COLUMNS="tput cols") otherwise the command "select" will not set the number of columns correctly for actual screen resolution. Information:checkwinsizeon Please try this script-example to see the effect: #!/bin/bash

Re: Unexpected word splitting on $* when IFS is unset

2017-06-24 Thread Robert Elz
Date:Sat, 24 Jun 2017 07:59:25 -0500 From:Eduardo =?utf-8?Q?A=2E_Bustamante_L=C3=B3pez?= Message-ID: <20170624125925.7vnb4kk35gh3obbk@debian> | I think we can all agree that the rules (and bugs) around | the expansion of $* are too complex. The bugs in various i

Re: Bug in select-command

2017-06-24 Thread Eduardo A . Bustamante López
On Sat, Jun 24, 2017 at 01:46:00PM +0200, sky...@top-email.net wrote: [...] > > ### DEFINE FUNCTIONS ### > _config-keymap() { > # Select keymap > # find keymap list, cut directory path and sort > local list_keymaps=( $(find /usr/share/kbd/keymaps/ > -type

Re: Unexpected word splitting on $* when IFS is unset

2017-06-24 Thread Eduardo A . Bustamante López
On Sat, Jun 24, 2017 at 09:10:34PM +0700, Robert Elz wrote: [...] > The bugs in various implementations cause problems, yes, dealing with > someone else's mistakes (and especially doing it in a way that things > still work when the bugs get fixed) can be difficult. > > But the rules, no, the rules

Re: Bug in select-command

2017-06-24 Thread Eduardo Bustamante
On Sat, Jun 24, 2017 at 9:46 AM, Eduardo A. Bustamante López wrote: [...] > For some reason though, the following fails to update the value of COLUMNS: [...] > echo \$- $- > echo cols $(tput cols) > command true # this should trigger? > select opt in "${options[@]}"; do > break > don

Re: Bug in select-command

2017-06-24 Thread Eduardo A . Bustamante López
Chet: I think the patch below could be a useful addition, to make the behavior in this case a little bit less surprising. *** /tmp/BdLnYa_shopt.def 2017-06-24 10:21:15.029707643 -0500 --- builtins/shopt.def 2017-06-24 10:17:00.540600773 -0500 *** *** 134,139 --- 134,140 -

Re: Unexpected word splitting on $* when IFS is unset

2017-06-24 Thread Chet Ramey
On 6/23/17 10:35 PM, Robert Elz wrote: > Date:Fri, 23 Jun 2017 11:39:45 -0400 > From:Greg Wooledge > Message-ID: <20170623153945.ga4...@eeg.ccf.org> > > | That's what I always thought too, but if commonly used shells like > | dash can't even agree on this, then I

Re: Bug in select-command

2017-06-24 Thread Chet Ramey
On 6/24/17 7:46 AM, sky...@top-email.net wrote: > It is necessary to refresh the variable $COLUMNS in a script (COLUMNS="tput > cols") otherwise the command "select" will not set the number of columns > correctly for actual screen resolution. So you are saying that the value of COLUMNS passed in

Re: Bug in select-command

2017-06-24 Thread Chet Ramey
On 6/24/17 10:46 AM, Eduardo A. Bustamante López wrote: > I think this is an easier way to reproduce the problem. I have a terminal > window with the following dimensions: > > dualbus@debian:~$ declare -p COLUMNS LINES > declare -- COLUMNS="191" > declare -- LINES="49" You haven't exported

Re: Bug in select-command

2017-06-24 Thread Eduardo A . Bustamante López
On Sat, Jun 24, 2017 at 01:17:23PM -0400, Chet Ramey wrote: [...] > You haven't exported these. If you had, the subshell started to run the > script would have the correct values. Hm. I think this may be a documentation / usability problem. The manual states the following: COLUMNS Us

Re: Fwd: Non-upstream patches for bash (2014)

2017-06-24 Thread Eduardo A . Bustamante López
I was looking through this old thread: http://seclists.org/oss-sec/2014/q3/851 It looks like the issue reported in there is still there: dualbus@debian:~$ LANG=zh_CN.GBK printf 'echo \u4e57\n' |LANG=zh_CN.GBK bash �\ dualbus@debian:~$ LANG=en_US.UTF8 printf 'echo \u4e57\n' |LANG=en_US.UTF8

Re: Fwd: Non-upstream patches for bash (2014)

2017-06-24 Thread George
On Sat, 2017-06-24 at 12:41 -0500, Eduardo A. Bustamante López wrote: > I was looking through this old thread: > http://seclists.org/oss-sec/2014/q3/851 > > It looks like the issue reported in there is still there: > >   dualbus@debian:~$ LANG=zh_CN.GBK printf 'echo \u4e57\n' |LANG=zh_CN.GBK bash

Re: Fwd: Non-upstream patches for bash (2014)

2017-06-24 Thread Eduardo A . Bustamante López
On Sat, Jun 24, 2017 at 04:46:47PM -0400, George wrote: [...] > I'm not seeing the problem here (at least, not in Bash or ksh - mksh and zsh > seem to have gotten it wrong...) You are right. I should get some sleep. FWIW, the original claim is that having a locale-dependent parser is a problem.

Re: Worth mentioning in documentation

2017-06-24 Thread Pádraig Brady
On 10/08/15 05:55, Eric Blake wrote: > On 08/10/2015 02:18 AM, Juanma wrote: > >> Here is another point I find confusing: I thought a "shell builtin" didn't >> have a separate binary executable file, like 'cd' (which cd => fail), > > Actually, POSIX requires that there be a separate 'cd' binary,