Troublesome checkwinsize (none) behaviour
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.2 -L/home/abuild/rpmbuild/BUILD/bash-4.2/../readline-6.2 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-suse-linux-gnu' -DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -D_GNU_SOURCE -DRECYCLES_PIDS -Wall -g -std=gnu89 -Wuninitialized -Wextra -Wno-unprototyped-calls -Wno-switch-enum -Wno-unused-variable -Wno-unused-parameter -ftree-loop-linear -pipe -fprofile-use uname output: Linux d88 3.7.10-1.11-desktop #1 SMP PREEMPT Thu May 16 20:27:27 UTC 2013 (adf31bb) x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-suse-linux-gnu Bash Version: 4.2 Patch Level: 42 Release Status: release Description: As subject says: * If checkwinsize is _not_ set the bash does not update the internal LINES and COLUMNS varaible during a command/job is running in foreground on same terminal. * If checkwinsize is set bash/libreadline does export LINES and COLUMNS breaking ncurses/TIOCGWINSZ based commands/jobs. both cause bug reports here. That is if I override the default and set the check_window_size to 1 in jobs.c I'll beaten by bug reports and upstream (compare e.g. with https://bugzilla.novell.com/show_bug.cgi?id=793536). If I do not change the upstream behaviour I'll also beaten by bug reports because know bash does not know about size changes during an other job is in foreground (compare e.g. with https://bugzilla.novell.com/show_bug.cgi?id=828877) Fix: The bash/libreadline may (IMHO) update LINES and COLUMNS after a job without exporting LINES and COLUMNS. Simply to have a correct command line behaviour of the bash its self after jobs had finished as well as for the jobs them self to not to depend on static LINES and COLUMNS but on TIOCGWINSZ only.
Re: Chained command prints password in Clear Text and breaks BASH Session until logout
Jason Sipula writes: > This fixed bash. So it does appear MySQL is disabling echo.Strange that it > does not re-enable it after it's finished running. I'll take this up with > the mysql folks. Most likely the second instance found the terminal already set to -echo after the first instance has started to read the password. Having two processes compete for input is never a good thing. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Troublesome checkwinsize (none) behaviour
On 7/12/13 5:57 AM, wer...@suse.de wrote: > Bash Version: 4.2 > Patch Level: 42 > Release Status: release > > Description: > As subject says: > * If checkwinsize is _not_ set the bash does not update the > internal LINES and COLUMNS varaible during a command/job is > running in foreground on same terminal. > * If checkwinsize is set bash/libreadline does export LINES and > COLUMNS breaking ncurses/TIOCGWINSZ based commands/jobs. > both cause bug reports here. That is if I override the default and > set the check_window_size to 1 in jobs.c I'll beaten by bug reports > and upstream (compare e.g. with > https://bugzilla.novell.com/show_bug.cgi?id=793536). > If I do not change the upstream behaviour I'll also beaten by bug > reports because know bash does not know about size changes during > an other job is in foreground > (compare e.g. with https://bugzilla.novell.com/show_bug.cgi?id=828877) > Fix: > The bash/libreadline may (IMHO) update LINES and COLUMNS after a job > without exporting LINES and COLUMNS. Simply to have a correct command > line behaviour of the bash its self after jobs had finished as well > as for the jobs them self to not to depend on static LINES and COLUMNS > but on TIOCGWINSZ only. Bash does not export LINES or COLUMNS. You can test this yourself by 1. Make sure that LINES and COLUMNS are not exported. They're not on my Mac OS X or RHEL systems, for instance 2. Make sure the checkwinsize option is enabled 3. Run sleep 10 and resize the terminal 4. echo $LINES and $COLUMNS and see they've been updated 5. Look at the output of export and note that LINES and COLUMNS are still not exported This is the output of those commands on an RHEL system: $ export | grep LINES $ export | grep COLUMNS $ echo $LINES $COLUMNS 30 80 $ shopt -s checkwinsize $ sleep 10 $ echo $LINES $COLUMNS 36 100 $ export | grep LINES $ export | grep COLUMNS $ Your analysis in bug 793536 is incomplete. Had you looked further, you would have discovered that the setenv calls in lib/readline/shell.c appear in a function (sh_set_lines_and_columns) that is superseded by a bash definition in variables.c. I would look further at whether or not (and where) COLUMNS is being exported. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Chained command prints password in Clear Text and breaks BASH Session until logout
So, in other words... User Error. I guess it makes sense why mysql would get grumpy if both mysqldump and mysql were both attempting to read from stdin, /dev/tty or whatever at the same time. I had [incorrectly] assumed that mysqldump would request input first, then mysql would after mysqldump closed it's hold on stdin. This was based on an assumption that keyed input could be given to only a single program at a time and that the "active" program would block others until it was finished. However it's now clear that both instances attempt to take control at the same time and end up fighting, leading to undefined behavior. There's a saying about assumptions that probably applies here... On Fri, Jul 12, 2013 at 3:30 AM, Andreas Schwab wrote: > Jason Sipula writes: > > > This fixed bash. So it does appear MySQL is disabling echo.Strange that > it > > does not re-enable it after it's finished running. I'll take this up with > > the mysql folks. > > Most likely the second instance found the terminal already set to -echo > after the first instance has started to read the password. Having two > processes compete for input is never a good thing. > > Andreas. > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different." >
Re: Troublesome checkwinsize (none) behaviour
Chet Ramey writes: > Bash does not export LINES or COLUMNS. But it is exported by other users of libreadline who don't override sh_set_lines_and_columns. So it is still a readline bug. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Troublesome checkwinsize (none) behaviour
On 7/12/13 11:10 AM, Andreas Schwab wrote: > Chet Ramey writes: > >> Bash does not export LINES or COLUMNS. > > But it is exported by other users of libreadline who don't override > sh_set_lines_and_columns. So it is still a readline bug. Maybe it should be an option, then. I disagree that it's a bug. I assert that it is the desired behavior in the overwhelming majority of cases, especially since it is the only sure way to pass this information to child processes. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
quotes in bash script
I want a script to execute the command: ls -alst "dir with spaces" The script looks like this : #! /bin/bash PARAMS_FOR_LS="-alst \"dir with spaces\"" echo $PARAMS_FOR_LS ls $PARAMS_FOR_LS when I execute the script: bash -x script.sh I get: + PARAMS_FOR_LS='-alst "dir with spaces"' + echo -alst '"dir' with 'spaces"' -alst "dir with spaces" + ls -alst '"dir' with 'spaces"' ls: cannot access "dir: No such file or directory ls: cannot access with: No such file or directory ls: cannot access spaces": No such file or directory why the extra quotes ??
Re: quotes in bash script
On Fri, 12 Jul 2013, gscant...@comcast.net wrote:
I want a script to execute the command:
ls -alst "dir with spaces"
The script looks like this :
#! /bin/bash
PARAMS_FOR_LS="-alst \"dir with spaces\""
echo $PARAMS_FOR_LS
ls $PARAMS_FOR_LS
$PARAMS_FOR_LS is subject to word splitting.
Try this instead:
PARAMS_FOR_LS=( -alst "dir with spaces" )
ls "${PARAMS_FOR_LS[@]}"
See also .
--
Chris F.A. Johnson,
Re: quotes in bash script
On Fri, Jul 12, 2013 at 9:48 PM, wrote: > I want a script to execute the command: > ls -alst "dir with spaces" > > > The script looks like this : > #! /bin/bash > > PARAMS_FOR_LS="-alst \"dir with spaces\"" > > echo $PARAMS_FOR_LS > > ls $PARAMS_FOR_LS > > > > when I execute the script: > bash -x script.sh > > > I get: > + PARAMS_FOR_LS='-alst "dir with spaces"' > + echo -alst '"dir' with 'spaces"' > -alst "dir with spaces" > + ls -alst '"dir' with 'spaces"' > ls: cannot access "dir: No such file or directory > ls: cannot access with: No such file or directory > ls: cannot access spaces": No such file or directory > > why the extra quotes ?? > > Quote Removal After the preceding expansions, all unquoted occurrences of the charac‐ ters \, ', and " that did not result from one of the above expansions are removed. The quotes are special for the shell only when they are literal if you put quotes in a variable or inside other quotes, they lose their special powers
