Re: Another "set" option?

[Pierre Gaston]

On Wed, Jul 10, 2013 at 8:35 PM, Geir Hauge  wrote:
> 2013/7/10 Bruce Korb 
>
>> This seems like a lot of obtuse bother:
>>
>> xtrace_setting=$(
>>re=$'\nxtrace[ \t]+on'
>>[[ $(set -o) =~ $re ]] && echo ' -x' || echo ' +x')
>>
>> if there were only some magic like ${BASH_SETTING_XTRACE} or
>> xtrace_setting=$(set -q xtrace) or something.  Could we get
>> something fairly straight forward for querying set/shopt state?
>> Thank you for considering.  Regards, Bruce
>>
>
> shopt -qo xtrace && xtrace=1
>

For the single letter options you can also use the standard: case $- in *x*) ...

Re: Here document / redirection / background process weirdness

[Chet Ramey]

On 3/5/13 7:52 AM, Martin Jackson wrote:

> Bash Version: 4.2
> Patch Level: 0
> Release Status: release
> 
> Description:
> When executing a here document in bash, with the here document piped to
> another instance of bash, where the here document contains "echo <&- &;
> wait", the here document gets executed twice. 

Thanks for the report.  This will be fixed in the next release of bash.

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: History file clobbered by multiple simultaneous exits

[Linda Walsh]

ge...@cs.hmc.edu wrote:

Locking should be used when truncating and writing the history
file.  (Yes, I know it's a pain in a portable program like
bash.)

Strictly speaking, locking is only half a solution, because
the net result will be that the saved history is taken from
a randomly chosen one of the multiple exiting shells.  But
that's better than the current situation where all history is lost.

What might be cooler would be to merge all the history lines
from all shells, in timestamp order.  But given the current
history file format, that seems...hard.


You shouldn't write to the same history file from multiple
sessions.  Encode the session name (or ttyname) in the history file name
Then they won't collide as you can only have 1 person logged in / tty.

Re: History file clobbered by multiple simultaneous exits

[Chris F.A. Johnson]

On Wed, 10 Jul 2013, ge...@cs.hmc.edu wrote:
...

What might be cooler would be to merge all the history lines
from all shells, in timestamp order.  But given the current
history file format, that seems...hard.


PROMPT_COMMAND='history -a "$HISTFILE"'

--
   Chris F.A. Johnson, 
   Author:
   Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress)
   Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)

Chained command prints password in Clear Text and breaks BASH Session until logout

[Jason Sipula]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib  -D_GNU_SOURCE
-DRECYCLES_PIDS  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fwrapv
uname output: Linux appsrv01.js.local 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue
Apr 23 19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 4.1
Patch Level: 2
Release Status: release

Description:

Reproducible from both an SSH session as well as directly at the console.

On BASH 4.1.x (4.1.2) running under CentOS 6.x (6.4 Final) and MySQL 5.1.x
(5.1.69). I believe this bug will persist on all distros running BASH 4.x.x

After running the chained command (see below "Repeat-By" section), BASH
allows a password field to be seen in Clear Text, and then the BASH session
breaks until BASH session is restarted (logout then login).

The purpose of the command is to dump the database "somedb" ... which would
normally dump to a text file for import later... but instead redirect
stdout to the stdin of the chained mysql command which will import all the
data from "somedb" into "someotherdb" on the same MySQL host. The command
works, but there's two problems.

MySQL correctly challenges for password of "someuser" to perform the
mysqldump part, but once you type in the password and hit ENTER, it skips
to a new blank line without the shell prompt and just sits. It is waiting
for you to type in the password for "someuser" as the second part of the
command (but does not prompt for this and it's not intuitive, it appears
as-if the command is running)... If you type, it's in clear text!
Potentially a major security issue there.

It gets worse...

After you hit ENTER a second time, the command will finish, and it will
return a fresh line with the shell prompt. Everything looks normal... but
try typing. Nothing will show at all, however it is sending the keys to the
shell and will execute commands if you type them in and hit ENTER. Each
successful command will return you to a fresh shell line, but same thing
happens until you log out and back in (to restart BASH). Also, while this
is happening, you can hit the ENTER key over and over and BASH will just
keep repeating the shell prompt on the same line.

Repeat-By:

At the shell, issue the command:

~]# mysqldump -u someuser -p somedb | mysql -u someuser -p -D someotherdb

Shouldn't need to run that command as root, but the mysql user must be
privileged enough to work with the two databases. To simplify things you
can replace "someuser" with root.

Thank you,

Jason Sipula
alup...@gmail.com

Re: Bash install on Windows 7 using SUA

[Lionel Cons]

On 2 July 2013 22:44, Eric Blake  wrote:
> On 07/02/2013 12:20 PM, Chris Irvine wrote:
>> I tried to download the BASH for my Windows 7 computer with SUA (services
>> for Unix installed).  The latest download script, config.guess, was used and
>> the configure command failed with an error.  I have attached a picture of
>> the error message in a Word document.
>
> Sheesh - you made people have to read a non-free file format to see a
> screenshot, instead of just copying and pasting the text of the error
> message itself.  Stunts like that cause undue network congestion, and
> alienate you from free software developers who try to stay as far away
> from proprietary software as possible.
>
> Your screenshot shows that your build error boils down to:
>
> loadmsgcat.c: In function `get_sysdep_segment_value':
> loadmsgcat.c:727: error: `uintmax_t' undeclared (first use in this function)
>
> which means your system has incomplete headers, and no one else has ever
> tried working around that bug.
>
> SUA is a rather wimpy porting platform.  Have you considered trying
> Cygwin instead (see cygwin.com), so that you don't have to put up with
> all the non-conforming incomplete POSIX garbage that Microsoft is
> pushing with their SUA platform?

The problem isn't 'whimpy platform', the problem is that the POSIX
APIs implemented by Window's 7 SUA are too old to be usable. SUA needs
an update to be competitive.

Lionel

Re: Chained command prints password in Clear Text and breaks BASH Session until logout

[Greg Wooledge]

On Wed, Jul 10, 2013 at 02:54:17PM -0700, Jason Sipula wrote:
> ~]# mysqldump -u someuser -p somedb | mysql -u someuser -p -D someotherdb

This isn't a bash issue.  Mysql is prompting for a password, either
on standard input or by directly opening /dev/tty.  In either case,
the issue is with mysql.  Once the pipeline has been constructed and
the two mysql processes have been executed, bash is no longer involved
at all.

Aw: Chained command prints password in Clear Text and breaks BASH Session until logout

[John Kearney]

   This isn't a but in bash.
   firstly once a program is started it takes over the input so the fact
   that your password is echoed to the terminal is because myspl allows it
   not bash, and in mysql defense this is the normal behaviour for command
   line tools.

   Secondly both mysqldump  and mysql start at the same time and can
   potentially be reading the password also at the same time.
   on some systems and for some apps it could happen that.

   password for mysqldump p1234
   password for mysql  p5678

   the way you are staring them you could potentially end up with

   mysqldump getting p5274
   mysql getting  p1638

   basically you should give the password on the command line to mysql.
   something like
   read -sp "Password:" Password
   mysqldump -u someuser --password ${Password} -p somedb | mysql -u
   someuser --password ${Password} -p -D someotherdb

   Gesendet: Mittwoch, 10. Juli 2013 um 23:54 Uhr
   Von: "Jason Sipula" 
   An: bug-bash@gnu.org
   Betreff: Chained command prints password in Clear Text and breaks BASH
   Session until logout
   Configuration Information [Automatically generated, do not change]:
   Machine: x86_64
   OS: linux-gnu
   Compiler: gcc
   Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
   -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
   -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
   -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE
   -DRECYCLES_PIDS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
   -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fwrapv
   uname output: Linux appsrv01.js.local 2.6.32-358.6.1.el6.x86_64 #1 SMP
   Tue
   Apr 23 19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
   Machine Type: x86_64-redhat-linux-gnu
   Bash Version: 4.1
   Patch Level: 2
   Release Status: release
   Description:
   Reproducible from both an SSH session as well as directly at the
   console.
   On BASH 4.1.x (4.1.2) running under CentOS 6.x (6.4 Final) and MySQL
   5.1.x
   (5.1.69). I believe this bug will persist on all distros running BASH
   4.x.x
   After running the chained command (see below "Repeat-By" section), BASH
   allows a password field to be seen in Clear Text, and then the BASH
   session
   breaks until BASH session is restarted (logout then login).
   The purpose of the command is to dump the database "somedb" ... which
   would
   normally dump to a text file for import later... but instead redirect
   stdout to the stdin of the chained mysql command which will import all
   the
   data from "somedb" into "someotherdb" on the same MySQL host. The
   command
   works, but there's two problems.
   MySQL correctly challenges for password of "someuser" to perform the
   mysqldump part, but once you type in the password and hit ENTER, it
   skips
   to a new blank line without the shell prompt and just sits. It is
   waiting
   for you to type in the password for "someuser" as the second part of
   the
   command (but does not prompt for this and it's not intuitive, it
   appears
   as-if the command is running)... If you type, it's in clear text!
   Potentially a major security issue there.
   It gets worse...
   After you hit ENTER a second time, the command will finish, and it will
   return a fresh line with the shell prompt. Everything looks normal...
   but
   try typing. Nothing will show at all, however it is sending the keys to
   the
   shell and will execute commands if you type them in and hit ENTER. Each
   successful command will return you to a fresh shell line, but same
   thing
   happens until you log out and back in (to restart BASH). Also, while
   this
   is happening, you can hit the ENTER key over and over and BASH will
   just
   keep repeating the shell prompt on the same line.
   Repeat-By:
   At the shell, issue the command:
   ~]# mysqldump -u someuser -p somedb | mysql -u someuser -p -D
   someotherdb
   Shouldn't need to run that command as root, but the mysql user must be
   privileged enough to work with the two databases. To simplify things
   you
   can replace "someuser" with root.
   Thank you,
   Jason Sipula
   alup...@gmail.com

Re: Chained command prints password in Clear Text and breaks BASH Session until logout

[Jason Sipula]

I probably should have filed two different reports for this. Sorry for any
confusion guys.

The password makes sense to me why it allows clear text...

The second issue is once the command terminates, bash session does not
behave normally at all. Nothing typed into the terminal over SSH or
directly on the console displays, however it does receive the keys. Also,
if you repeatedly hit ENTER key, instead of skipping to new line, it just
repeats the bash prompt over and over in a single line. So far restarting
bash session (by logging out then back in) is the only way I have found to
"fix" the session and return to normal functionality.


On Thu, Jul 11, 2013 at 10:47 AM, John Kearney  wrote:

>
> This isn't a but in bash.
> firstly once a program is started it takes over the input so the fact that
> your password is echoed to the terminal is because myspl allows it not
> bash, and in mysql defense this is the normal behaviour for command line
> tools.
>
> Secondly both mysqldump  and mysql start at the same time and can
> potentially be reading the password also at the same time.
> on some systems and for some apps it could happen that.
>
> password for mysqldump p1234
> password for mysql  p5678
>
> the way you are staring them you could potentially end up with
>
> mysqldump getting p5274
> mysql getting  p1638
>
> basically you should give the password on the command line to mysql.
>
> something like
> read -sp "Password:" Password
> mysqldump -u someuser --password ${Password} -p somedb | mysql -u someuser
> --password ${Password} -p -D someotherdb
>
>  *Gesendet:* Mittwoch, 10. Juli 2013 um 23:54 Uhr
> *Von:* "Jason Sipula" 
> *An:* bug-bash@gnu.org
> *Betreff:* Chained command prints password in Clear Text and breaks BASH
> Session until logout
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
> -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
> -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE
> -DRECYCLES_PIDS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fwrapv
> uname output: Linux appsrv01.js.local 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue
> Apr 23 19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-redhat-linux-gnu
>
> Bash Version: 4.1
> Patch Level: 2
> Release Status: release
>
> Description:
>
> Reproducible from both an SSH session as well as directly at the console.
>
> On BASH 4.1.x (4.1.2) running under CentOS 6.x (6.4 Final) and MySQL 5.1.x
> (5.1.69). I believe this bug will persist on all distros running BASH 4.x.x
>
> After running the chained command (see below "Repeat-By" section), BASH
> allows a password field to be seen in Clear Text, and then the BASH session
> breaks until BASH session is restarted (logout then login).
>
> The purpose of the command is to dump the database "somedb" ... which would
> normally dump to a text file for import later... but instead redirect
> stdout to the stdin of the chained mysql command which will import all the
> data from "somedb" into "someotherdb" on the same MySQL host. The command
> works, but there's two problems.
>
> MySQL correctly challenges for password of "someuser" to perform the
> mysqldump part, but once you type in the password and hit ENTER, it skips
> to a new blank line without the shell prompt and just sits. It is waiting
> for you to type in the password for "someuser" as the second part of the
> command (but does not prompt for this and it's not intuitive, it appears
> as-if the command is running)... If you type, it's in clear text!
> Potentially a major security issue there.
>
> It gets worse...
>
> After you hit ENTER a second time, the command will finish, and it will
> return a fresh line with the shell prompt. Everything looks normal... but
> try typing. Nothing will show at all, however it is sending the keys to the
> shell and will execute commands if you type them in and hit ENTER. Each
> successful command will return you to a fresh shell line, but same thing
> happens until you log out and back in (to restart BASH). Also, while this
> is happening, you can hit the ENTER key over and over and BASH will just
> keep repeating the shell prompt on the same line.
>
> Repeat-By:
>
> At the shell, issue the command:
>
> ~]# mysqldump -u someuser -p somedb | mysql -u someuser -p -D someotherdb
>
> Shouldn't need to run that command as root, but the mysql user must be
> privileged enough to work with the two databases. To simplify things you
> can replace "someuser" with root.
>
> Thank you,
>
> Jason Sipula
> alup...@gmail.com
>

Re: Chained command prints password in Clear Text and breaks BASH Session until logout

[Greg Wooledge]

On Thu, Jul 11, 2013 at 10:47:12AM -0700, Jason Sipula wrote:
> I still think this is a bash issue. After the command terminates, you must
> restart your bash session to return to normal functionality. Nothing typed
> into the terminal displays but it does receive it.

If the terminal has been messed up (which happens frequently when programs
exit abnormally), then you'll need to run "reset" or some other command
to reset the terminal.

> Perhaps I'm
> misunderstanding what bash's job is... I was under the impression the shell
> was responsible for displaying text in the terminal.

That's incorrect.  The terminal itself is responsible for displaying text
in the terminal.  Bash simply reads commands from a file descriptor and
runs them.  When the commands are running, they interact directly with
the terminal, while bash goes to sleep.


On Thu, Jul 11, 2013 at 07:47:47PM +0200, John Kearney wrote:
> 
>This isn't a but in bash.
>firstly once a program is started it takes over the input so the fact
>that your password is echoed to the terminal is because myspl allows it
>not bash, and in mysql defense this is the normal behaviour for command
>line tools.

Well.  The issue is really that he's trying to run two separate instances
of "mysql -p" in the same terminal at the same time.  They're competing
for the same input stream, and that never works well.

There is no "normal behavior" among programs that accept a password for
authentication.  Some of them open /dev/tty directly.  Some of them
read from standard input.  Some of them accept a password in a command
line argument, or in an environment variable -- both of which are bad.

>Secondly both mysqldump  and mysql start at the same time and can
>potentially be reading the password also at the same time.

(You described multiple stdin readers here.  I won't repeat that part.)

>basically you should give the password on the command line to mysql.
>something like
>read -sp "Password:" Password
>mysqldump -u someuser --password ${Password} -p somedb | mysql -u
>someuser --password ${Password} -p -D someotherdb

First: use more quotes.  "$Password", not ${Password} or $Password.

Second: passing the password (which is presumably supposd to remain
secret) on the command line allows it to be visible to every user on
the system.  On 99% of Unix systems in the world, anyway.  There are
undoubtedly some small number where user can't run "ps -ef", or where
they get limited output from it, but you shouldn't assume.

There may be some setups where this solution is adequate, once it's
been quoted correctly.  In most setups, it is unsafe.  It's up to Jason
to decide whether his setup can permit this.

I'd ask a mysql list for advice with this.  It's not something that can
be generalized across applications.

Aw: Re: Chained command prints password in Clear Text and breaks BASH Session until logout

[John Kearney]

   Sorry made a typo in the last email  I meant try
   stty echo




   sounds like echo is turned off
   try typing
   stty echo
   when you  you say you don't see any output.
   And if echoing is turned off it was probably turned off my mysql.
   Gesendet: Donnerstag, 11. Juli 2013 um 19:53 Uhr
   Von: "Jason Sipula" 
   An: Kein Empfänger
   Cc: bug-bash@gnu.org
   Betreff: Re: Chained command prints password in Clear Text and breaks
   BASH Session until logout
   I probably should have filed two different reports for this. Sorry for
   any
   confusion guys.
   The password makes sense to me why it allows clear text...
   The second issue is once the command terminates, bash session does not
   behave normally at all. Nothing typed into the terminal over SSH or
   directly on the console displays, however it does receive the keys.
   Also,
   if you repeatedly hit ENTER key, instead of skipping to new line, it
   just
   repeats the bash prompt over and over in a single line. So far
   restarting
   bash session (by logging out then back in) is the only way I have found
   to
   "fix" the session and return to normal functionality.
   On Thu, Jul 11, 2013 at 10:47 AM, John Kearney 
   wrote:
   >
   > This isn't a but in bash.
   > firstly once a program is started it takes over the input so the fact
   that
   > your password is echoed to the terminal is because myspl allows it
   not
   > bash, and in mysql defense this is the normal behaviour for command
   line
   > tools.
   >
   > Secondly both mysqldump and mysql start at the same time and can
   > potentially be reading the password also at the same time.
   > on some systems and for some apps it could happen that.
   >
   > password for mysqldump p1234
   > password for mysql p5678
   >
   > the way you are staring them you could potentially end up with
   >
   > mysqldump getting p5274
   > mysql getting p1638
   >
   > basically you should give the password on the command line to mysql.
   >
   > something like
   > read -sp "Password:" Password
   > mysqldump -u someuser --password ${Password} -p somedb | mysql -u
   someuser
   > --password ${Password} -p -D someotherdb
   >
   > *Gesendet:* Mittwoch, 10. Juli 2013 um 23:54 Uhr
   > *Von:* "Jason Sipula" 
   > *An:* bug-bash@gnu.org
   > *Betreff:* Chained command prints password in Clear Text and breaks
   BASH
   > Session until logout
   > Configuration Information [Automatically generated, do not change]:
   > Machine: x86_64
   > OS: linux-gnu
   > Compiler: gcc
   > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
   > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
   > -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale'
   -DPACKAGE='bash'
   > -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE
   > -DRECYCLES_PIDS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
   -fexceptions
   > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
   -fwrapv
   > uname output: Linux appsrv01.js.local 2.6.32-358.6.1.el6.x86_64 #1
   SMP Tue
   > Apr 23 19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
   > Machine Type: x86_64-redhat-linux-gnu
   >
   > Bash Version: 4.1
   > Patch Level: 2
   > Release Status: release
   >
   > Description:
   >
   > Reproducible from both an SSH session as well as directly at the
   console.
   >
   > On BASH 4.1.x (4.1.2) running under CentOS 6.x (6.4 Final) and MySQL
   5.1.x
   > (5.1.69). I believe this bug will persist on all distros running BASH
   4.x.x
   >
   > After running the chained command (see below "Repeat-By" section),
   BASH
   > allows a password field to be seen in Clear Text, and then the BASH
   session
   > breaks until BASH session is restarted (logout then login).
   >
   > The purpose of the command is to dump the database "somedb" ... which
   would
   > normally dump to a text file for import later... but instead redirect
   > stdout to the stdin of the chained mysql command which will import
   all the
   > data from "somedb" into "someotherdb" on the same MySQL host. The
   command
   > works, but there's two problems.
   >
   > MySQL correctly challenges for password of "someuser" to perform the
   > mysqldump part, but once you type in the password and hit ENTER, it
   skips
   > to a new blank line without the shell prompt and just sits. It is
   waiting
   > for you to type in the password for "someuser" as the second part of
   the
   > command (but does not prompt for this and it's not intuitive, it
   appears
   > as-if the command is running)... If you type, it's in clear text!
   > Potentially a major security issue there.
   >
   > It gets worse...
   >
   > After you hit ENTER a second time, the command will finish, and it
   will
   > return a fresh line with the shell prompt. Everything looks normal...
   but
   > try typing. Nothing will show at all, however it is sending the keys
   to the
   > shell and will execute commands if you type them in and hit ENTER

Re: Re: Chained command prints password in Clear Text and breaks BASH Session until logout

[Jason Sipula]

Bingo.

~]# stty echo

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.

Thank you to everyone!


On Thu, Jul 11, 2013 at 11:00 AM, John Kearney  wrote:

>  sounds like echo is turned off
> try typing
> stty +echo
> when you  you say you don't see any output.
> And if its turned off it was probably turned off my mysql.
> *Gesendet:* Donnerstag, 11. Juli 2013 um 19:53 Uhr
> *Von:* "Jason Sipula" 
> *An:* Kein Empfänger
> *Cc:* bug-bash@gnu.org
> *Betreff:* Re: Chained command prints password in Clear Text and breaks
> BASH Session until logout
> I probably should have filed two different reports for this. Sorry for any
> confusion guys.
>
> The password makes sense to me why it allows clear text...
>
> The second issue is once the command terminates, bash session does not
> behave normally at all. Nothing typed into the terminal over SSH or
> directly on the console displays, however it does receive the keys. Also,
> if you repeatedly hit ENTER key, instead of skipping to new line, it just
> repeats the bash prompt over and over in a single line. So far restarting
> bash session (by logging out then back in) is the only way I have found to
> "fix" the session and return to normal functionality.
>
>
> On Thu, Jul 11, 2013 at 10:47 AM, John Kearney  wrote:
>
> >
> > This isn't a but in bash.
> > firstly once a program is started it takes over the input so the fact
> that
> > your password is echoed to the terminal is because myspl allows it not
> > bash, and in mysql defense this is the normal behaviour for command line
> > tools.
> >
> > Secondly both mysqldump and mysql start at the same time and can
> > potentially be reading the password also at the same time.
> > on some systems and for some apps it could happen that.
> >
> > password for mysqldump p1234
> > password for mysql p5678
> >
> > the way you are staring them you could potentially end up with
> >
> > mysqldump getting p5274
> > mysql getting p1638
> >
> > basically you should give the password on the command line to mysql.
> >
> > something like
> > read -sp "Password:" Password
> > mysqldump -u someuser --password ${Password} -p somedb | mysql -u
> someuser
> > --password ${Password} -p -D someotherdb
> >
> > *Gesendet:* Mittwoch, 10. Juli 2013 um 23:54 Uhr
> > *Von:* "Jason Sipula" 
> > *An:* bug-bash@gnu.org
> > *Betreff:* Chained command prints password in Clear Text and breaks BASH
>
> > Session until logout
> > Configuration Information [Automatically generated, do not change]:
> > Machine: x86_64
> > OS: linux-gnu
> > Compiler: gcc
> > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
> > -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
> > -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE
> > -DRECYCLES_PIDS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fwrapv
> > uname output: Linux appsrv01.js.local 2.6.32-358.6.1.el6.x86_64 #1 SMP
> Tue
> > Apr 23 19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> > Machine Type: x86_64-redhat-linux-gnu
> >
> > Bash Version: 4.1
> > Patch Level: 2
> > Release Status: release
> >
> > Description:
> >
> > Reproducible from both an SSH session as well as directly at the console.
> >
> > On BASH 4.1.x (4.1.2) running under CentOS 6.x (6.4 Final) and MySQL
> 5.1.x
> > (5.1.69). I believe this bug will persist on all distros running BASH
> 4.x.x
> >
> > After running the chained command (see below "Repeat-By" section), BASH
> > allows a password field to be seen in Clear Text, and then the BASH
> session
> > breaks until BASH session is restarted (logout then login).
> >
> > The purpose of the command is to dump the database "somedb" ... which
> would
> > normally dump to a text file for import later... but instead redirect
> > stdout to the stdin of the chained mysql command which will import all
> the
> > data from "somedb" into "someotherdb" on the same MySQL host. The command
> > works, but there's two problems.
> >
> > MySQL correctly challenges for password of "someuser" to perform the
> > mysqldump part, but once you type in the password and hit ENTER, it skips
> > to a new blank line without the shell prompt and just sits. It is waiting
> > for you to type in the password for "someuser" as the second part of the
> > command (but does not prompt for this and it's not intuitive, it appears
> > as-if the command is running)... If you type, it's in clear text!
> > Potentially a major security issue there.
> >
> > It gets worse...
> >
> > After you hit ENTER a second time, the command will finish, and it will
> > return a fresh line with the shell prompt. Everything looks normal... but
> > try typing. Nothing will show at all, however it is sending the keys to
> the
> > shell and will execu

Re: Chained command prints password in Clear Text and breaks BASH Session until logout

[Greg Wooledge]

On Thu, Jul 11, 2013 at 10:53:11AM -0700, Jason Sipula wrote:
> The second issue is once the command terminates, bash session does not
> behave normally at all. Nothing typed into the terminal over SSH or
> directly on the console displays, however it does receive the keys. Also,
> if you repeatedly hit ENTER key, instead of skipping to new line, it just
> repeats the bash prompt over and over in a single line.

I see that a lot.  It's because the terminal has been left in an abnormal
state after a process exited.  Running "reset" should fix it.

> So far restarting
> bash session (by logging out then back in) is the only way I have found to
> "fix" the session and return to normal functionality.

Part of your login (or logout) procedure probably resets the terminal,
which would explain why this works for you.

Re: Chained command prints password in Clear Text and breaks BASH Session until logout

[Jason Sipula]

You learn something new every day!

After your explanations, this situation makes perfect sense to me now. I
was attempting to quickly clone a database to basically rename it since
mysql removed the rename command a while ago (it was dangerous apparently).

It's pretty awesome that you guys took the time to explain this to me
instead of just blowing me off. Thank you very much.

-Jason


On Thu, Jul 11, 2013 at 11:04 AM, Greg Wooledge  wrote:

> On Thu, Jul 11, 2013 at 10:47:12AM -0700, Jason Sipula wrote:
> > I still think this is a bash issue. After the command terminates, you
> must
> > restart your bash session to return to normal functionality. Nothing
> typed
> > into the terminal displays but it does receive it.
>
> If the terminal has been messed up (which happens frequently when programs
> exit abnormally), then you'll need to run "reset" or some other command
> to reset the terminal.
>
> > Perhaps I'm
> > misunderstanding what bash's job is... I was under the impression the
> shell
> > was responsible for displaying text in the terminal.
>
> That's incorrect.  The terminal itself is responsible for displaying text
> in the terminal.  Bash simply reads commands from a file descriptor and
> runs them.  When the commands are running, they interact directly with
> the terminal, while bash goes to sleep.
>
>
> On Thu, Jul 11, 2013 at 07:47:47PM +0200, John Kearney wrote:
> >
> >This isn't a but in bash.
> >firstly once a program is started it takes over the input so the fact
> >that your password is echoed to the terminal is because myspl allows
> it
> >not bash, and in mysql defense this is the normal behaviour for
> command
> >line tools.
>
> Well.  The issue is really that he's trying to run two separate instances
> of "mysql -p" in the same terminal at the same time.  They're competing
> for the same input stream, and that never works well.
>
> There is no "normal behavior" among programs that accept a password for
> authentication.  Some of them open /dev/tty directly.  Some of them
> read from standard input.  Some of them accept a password in a command
> line argument, or in an environment variable -- both of which are bad.
>
> >Secondly both mysqldump  and mysql start at the same time and can
> >potentially be reading the password also at the same time.
>
> (You described multiple stdin readers here.  I won't repeat that part.)
>
> >basically you should give the password on the command line to mysql.
> >something like
> >read -sp "Password:" Password
> >mysqldump -u someuser --password ${Password} -p somedb | mysql -u
> >someuser --password ${Password} -p -D someotherdb
>
> First: use more quotes.  "$Password", not ${Password} or $Password.
>
> Second: passing the password (which is presumably supposd to remain
> secret) on the command line allows it to be visible to every user on
> the system.  On 99% of Unix systems in the world, anyway.  There are
> undoubtedly some small number where user can't run "ps -ef", or where
> they get limited output from it, but you shouldn't assume.
>
> There may be some setups where this solution is adequate, once it's
> been quoted correctly.  In most setups, it is unsafe.  It's up to Jason
> to decide whether his setup can permit this.
>
> I'd ask a mysql list for advice with this.  It's not something that can
> be generalized across applications.
>

Aw: Re: Re: Chained command prints password in Clear Text and breaks BASH Session until logout

[John Kearney]

   Typically when a program has this sort of a problem I just save and
   restore the context myself.

   SavedContext="$(stty -g )"

   read -sp "Password:" Password
   mysqldump -u someuser --password=${Password} somedb | mysql -u someuser
   --password=${Password} -D someotherdb

   # Restore Terminal Context.
   stty "${SavedContext}"


   And note your orginal example was wrong.

   -p in the following is to speciy the password
   mysqldump -u someuser -p somedb | mysql -u someuser -p -D someotherdb

   so you are saying the password to someuser is somedb and not giving a
   database.
   in the second case you are saying that the password to someuser is -D



   Gesendet: Donnerstag, 11. Juli 2013 um 20:05 Uhr
   Von: "Jason Sipula" 
   An: "John Kearney" 
   Cc: bug-bash@gnu.org
   Betreff: Re: Re: Chained command prints password in Clear Text and
   breaks BASH Session until logout
   Bingo.
   ~]# stty echo
   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.
   Thank you to everyone!
   On Thu, Jul 11, 2013 at 11:00 AM, John Kearney 
   wrote:
   > sounds like echo is turned off
   > try typing
   > stty +echo
   > when you you say you don't see any output.
   > And if its turned off it was probably turned off my mysql.
   > *Gesendet:* Donnerstag, 11. Juli 2013 um 19:53 Uhr
   > *Von:* "Jason Sipula" 
   > *An:* Kein Empfänger
   > *Cc:* bug-bash@gnu.org
   > *Betreff:* Re: Chained command prints password in Clear Text and
   breaks
   > BASH Session until logout
   > I probably should have filed two different reports for this. Sorry
   for any
   > confusion guys.
   >
   > The password makes sense to me why it allows clear text...
   >
   > The second issue is once the command terminates, bash session does
   not
   > behave normally at all. Nothing typed into the terminal over SSH or
   > directly on the console displays, however it does receive the keys.
   Also,
   > if you repeatedly hit ENTER key, instead of skipping to new line, it
   just
   > repeats the bash prompt over and over in a single line. So far
   restarting
   > bash session (by logging out then back in) is the only way I have
   found to
   > "fix" the session and return to normal functionality.
   >
   >
   > On Thu, Jul 11, 2013 at 10:47 AM, John Kearney 
   wrote:
   >
   > >
   > > This isn't a but in bash.
   > > firstly once a program is started it takes over the input so the
   fact
   > that
   > > your password is echoed to the terminal is because myspl allows it
   not
   > > bash, and in mysql defense this is the normal behaviour for command
   line
   > > tools.
   > >
   > > Secondly both mysqldump and mysql start at the same time and can
   > > potentially be reading the password also at the same time.
   > > on some systems and for some apps it could happen that.
   > >
   > > password for mysqldump p1234
   > > password for mysql p5678
   > >
   > > the way you are staring them you could potentially end up with
   > >
   > > mysqldump getting p5274
   > > mysql getting p1638
   > >
   > > basically you should give the password on the command line to
   mysql.
   > >
   > > something like
   > > read -sp "Password:" Password
   > > mysqldump -u someuser --password ${Password} -p somedb | mysql -u
   > someuser
   > > --password ${Password} -p -D someotherdb
   > >
   > > *Gesendet:* Mittwoch, 10. Juli 2013 um 23:54 Uhr
   > > *Von:* "Jason Sipula" 
   > > *An:* bug-bash@gnu.org
   > > *Betreff:* Chained command prints password in Clear Text and breaks
   BASH
   >
   > > Session until logout
   > > Configuration Information [Automatically generated, do not change]:
   > > Machine: x86_64
   > > OS: linux-gnu
   > > Compiler: gcc
   > > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
   > > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
   > > -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale'
   -DPACKAGE='bash'
   > > -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE
   > > -DRECYCLES_PIDS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
   -fexceptions
   > > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
   -fwrapv
   > > uname output: Linux appsrv01.js.local 2.6.32-358.6.1.el6.x86_64 #1
   SMP
   > Tue
   > > Apr 23 19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
   > > Machine Type: x86_64-redhat-linux-gnu
   > >
   > > Bash Version: 4.1
   > > Patch Level: 2
   > > Release Status: release
   > >
   > > Description:
   > >
   > > Reproducible from both an SSH session as well as directly at the
   console.
   > >
   > > On BASH 4.1.x (4.1.2) running under CentOS 6.x (6.4 Final) and
   MySQL
   > 5.1.x
   > > (5.1.69). I believe this bug will persist on all distros running
   BASH
   > 4.x.x
   > >
   > > After running the chained command (see below "Repeat-By" section),
   BASH
   > > allows a password field to

Re: Re: Re: Chained command prints password in Clear Text and breaks BASH Session until logout

[Jason Sipula]

Hmm... on my system. doing a

~]# mysql -u username -p

Makes mysql prompt for password. I usually do this when I'm logging into
mysql directly instead of programmically so that i don't have to type the
clear text password into the terminal. Maybe a mysql version thing? I'm on
5.1.x under centos 6.x


On Thu, Jul 11, 2013 at 11:34 AM, John Kearney  wrote:

>  Typically when a program has this sort of a problem I just save and
> restore the context myself.
>
> SavedContext="$(stty -g )"
>
> read -sp "Password:" Password
> mysqldump -u someuser --password=${Password} somedb | mysql -u someuser
> --password=${Password} -D someotherdb
>
> # Restore Terminal Context.
> stty "${SavedContext}"
>
>
> And note your orginal example was wrong.
>
> -p in the following is to speciy the password
> mysqldump -u someuser -p somedb | mysql -u someuser -p -D someotherdb
>
> so you are saying the password to someuser is somedb and not giving a
> database.
> in the second case you are saying that the password to someuser is -D
>
>
>
> *Gesendet:* Donnerstag, 11. Juli 2013 um 20:05 Uhr
> *Von:* "Jason Sipula" 
> *An:* "John Kearney" 
> *Cc:* bug-bash@gnu.org
> *Betreff:* Re: Re: Chained command prints password in Clear Text and
> breaks BASH Session until logout
> Bingo.
>
> ~]# stty echo
>
> 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.
>
> Thank you to everyone!
>
>
> On Thu, Jul 11, 2013 at 11:00 AM, John Kearney  wrote:
>
> > sounds like echo is turned off
> > try typing
> > stty +echo
> > when you you say you don't see any output.
> > And if its turned off it was probably turned off my mysql.
> > *Gesendet:* Donnerstag, 11. Juli 2013 um 19:53 Uhr
> > *Von:* "Jason Sipula" 
> > *An:* Kein Empfänger
> > *Cc:* bug-bash@gnu.org
> > *Betreff:* Re: Chained command prints password in Clear Text and breaks
> > BASH Session until logout
> > I probably should have filed two different reports for this. Sorry for
> any
> > confusion guys.
> >
> > The password makes sense to me why it allows clear text...
> >
> > The second issue is once the command terminates, bash session does not
> > behave normally at all. Nothing typed into the terminal over SSH or
> > directly on the console displays, however it does receive the keys. Also,
> > if you repeatedly hit ENTER key, instead of skipping to new line, it just
> > repeats the bash prompt over and over in a single line. So far restarting
> > bash session (by logging out then back in) is the only way I have found
> to
> > "fix" the session and return to normal functionality.
> >
> >
> > On Thu, Jul 11, 2013 at 10:47 AM, John Kearney 
> wrote:
> >
> > >
> > > This isn't a but in bash.
> > > firstly once a program is started it takes over the input so the fact
> > that
> > > your password is echoed to the terminal is because myspl allows it not
> > > bash, and in mysql defense this is the normal behaviour for command
> line
> > > tools.
> > >
> > > Secondly both mysqldump and mysql start at the same time and can
> > > potentially be reading the password also at the same time.
> > > on some systems and for some apps it could happen that.
> > >
> > > password for mysqldump p1234
> > > password for mysql p5678
> > >
> > > the way you are staring them you could potentially end up with
> > >
> > > mysqldump getting p5274
> > > mysql getting p1638
> > >
> > > basically you should give the password on the command line to mysql.
> > >
> > > something like
> > > read -sp "Password:" Password
> > > mysqldump -u someuser --password ${Password} -p somedb | mysql -u
> > someuser
> > > --password ${Password} -p -D someotherdb
> > >
> > > *Gesendet:* Mittwoch, 10. Juli 2013 um 23:54 Uhr
> > > *Von:* "Jason Sipula" 
> > > *An:* bug-bash@gnu.org
> > > *Betreff:* Chained command prints password in Clear Text and breaks
> BASH
> >
> > > Session until logout
> > > Configuration Information [Automatically generated, do not change]:
> > > Machine: x86_64
> > > OS: linux-gnu
> > > Compiler: gcc
> > > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> > > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
> > > -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
> > > -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE
> > > -DRECYCLES_PIDS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> > > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fwrapv
> > > uname output: Linux appsrv01.js.local 2.6.32-358.6.1.el6.x86_64 #1 SMP
> > Tue
> > > Apr 23 19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> > > Machine Type: x86_64-redhat-linux-gnu
> > >
> > > Bash Version: 4.1
> > > Patch Level: 2
> > > Release Status: release
> > >
> > > Description:
> > >
> > > Reproducible from both an SSH session as well as directly at the
> console.
> > >
> > > On BASH 4.1.x (4.1.2) running under CentOS 6.x (6.4 Final) and MySQ

Re: Chained command prints password in Clear Text and breaks BASH Session until logout

[Chris Down]

On 12 Jul 2013 01:29, "Chris Down"  wrote:
> What does this have to do with bash? This is almost certainly an issue
with your terminal it MySQL client. What about this would constitute a bash
bug?

s/\bit\b/or/

Re: Chained command prints password in Clear Text and breaks BASH Session until logout

[Chris Down]

On 12 Jul 2013 01:25, "Jason Sipula"  wrote:
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
> -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash'
> -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib  -D_GNU_SOURCE
> -DRECYCLES_PIDS  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fwrapv
> uname output: Linux appsrv01.js.local 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue
> Apr 23 19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-redhat-linux-gnu
>
> Bash Version: 4.1
> Patch Level: 2
> Release Status: release
>
> Description:
>
> Reproducible from both an SSH session as well as directly at the console.
>
> On BASH 4.1.x (4.1.2) running under CentOS 6.x (6.4 Final) and MySQL 5.1.x
> (5.1.69). I believe this bug will persist on all distros running BASH
4.x.x
>
> After running the chained command (see below "Repeat-By" section), BASH
> allows a password field to be seen in Clear Text, and then the BASH
session
> breaks until BASH session is restarted (logout then login).
>
> The purpose of the command is to dump the database "somedb" ... which
would
> normally dump to a text file for import later... but instead redirect
> stdout to the stdin of the chained mysql command which will import all the
> data from "somedb" into "someotherdb" on the same MySQL host. The command
> works, but there's two problems.
>
> MySQL correctly challenges for password of "someuser" to perform the
> mysqldump part, but once you type in the password and hit ENTER, it skips
> to a new blank line without the shell prompt and just sits. It is waiting
> for you to type in the password for "someuser" as the second part of the
> command (but does not prompt for this and it's not intuitive, it appears
> as-if the command is running)... If you type, it's in clear text!
> Potentially a major security issue there.
>
> It gets worse...
>
> After you hit ENTER a second time, the command will finish, and it will
> return a fresh line with the shell prompt. Everything looks normal... but
> try typing. Nothing will show at all, however it is sending the keys to
the
> shell and will execute commands if you type them in and hit ENTER. Each
> successful command will return you to a fresh shell line, but same thing
> happens until you log out and back in (to restart BASH). Also, while this
> is happening, you can hit the ENTER key over and over and BASH will just
> keep repeating the shell prompt on the same line.
>
> Repeat-By:
>
> At the shell, issue the command:
>
> ~]# mysqldump -u someuser -p somedb | mysql -u someuser -p -D someotherdb
>
> Shouldn't need to run that command as root, but the mysql user must be
> privileged enough to work with the two databases. To simplify things you
> can replace "someuser" with root.
>
> Thank you,
>
> Jason Sipula
> alup...@gmail.com

What does this have to do with bash? This is almost certainly an issue with
your terminal it MySQL client. What about this would constitute a bash bug?

Re: having bash display real tabs for tab characters...

[Linda Walsh]

Revisiting this...

Chet Ramey wrote:

On 4/25/13 8:45 AM, Greg Wooledge wrote:


If you think Bash is misbehaving, submit a patch, or wait for Chet to
comment on one of these threads.


I don't plan to comment or make any changes.  The demand for this
feature seems vanishingly small.




 And growing.

From the termcap source files:

# As the ANSI/ECMA-48 standard and variants take firmer hold, and as
# character-cell terminals are increasingly replaced by X displays, much
# of this file is becoming a historical document (this is part of the
# reason for the new organization, which puts ANSI types, xterm, Unix
# consoles, and vt100 up front in confidence that this will catch 95% of
# new hardware).

-

95% of new HW supports variable tabs according to this document.
I wouldn't call that vanishingly small, but of growing importance.

In addition to ANSI standards, it also applies to "linux" terminals as
well as the console.

I've switched to TS=2 upon login, mainly because of perl displaying
and lining up it's error messages and debugger messages based on tab
settings (if you have tab in your input file, it displays tab on the
output file.  You can fit alot more on the screen when you only indent
2 spaces vs. 8. (some like 4).  Whatever the user preference is -- a bad
trend is intermixing spaces & tabs to get non-8-space tabs.

This is bad because different people with different tab settings won't
have such files indented properly, whereas people who use tabs to indent
will find it portable to anyone else's system -- even if they prefer
a 6 space tab vs. 3.  If tabs have been used, you can change to your
favored indentation by changing the tab expansion in your editor and
a few other utils.  If a source has been indented with mixed
tabs/spaces, it needs to be run through a tab-conversion program leading
to many 'diffs', for those looking at diffs in source code (I know howto
tell diff to ignore all -w(hite) space change ("-w")), but many diff
utils don't support that.

I find it more than a little strange that someone on the POSIX committee
wouldn't realize the important of the ANSI standards.

It seems like it would simplify the code to actually display a 'tab'
rather than having to calculate the expansion.

Please rethink this issue as it appears that it isn't as small as one
might think and is similar to the reason why hi-rez displays have been
slow to pick up in demand -- because of bad-implementations that tied
text size to pixel density (changing in HTML5), as pixels have redefined
to be 1/96th of an inch, regardless of HW).  This was fixed because
people couldn't follow standards using device independent character
sizing.

I would say people don't favor tabs heavily now, because tabs are fixed
in size.  I.e. the reasons behind your saying the demand for the feature
is vanishingly small is because of broken utilities that always expand
tabs to mod/8 columns regardless of user preferences.

Bash could be leading edge in this area by supporting a tab-set command
(so bash, as a side effect, would continue to know where the cursor is
on the line).

Re: having bash display real tabs for tab characters...

[Eric Blake]

On 07/11/2013 04:06 PM, Linda Walsh wrote:
> Revisiting this...
> 
> Chet Ramey wrote:
>> On 4/25/13 8:45 AM, Greg Wooledge wrote:
>>
>>> If you think Bash is misbehaving, submit a patch, or wait for Chet to
>>> comment on one of these threads.
>>
>> I don't plan to comment or make any changes.  The demand for this
>> feature seems vanishingly small.
> 

> 
> Bash could be leading edge in this area by supporting a tab-set command
> (so bash, as a side effect, would continue to know where the cursor is
> on the line).

This is YOUR itch, so YOU get to scratch it.  Apparently, no one else is
interested in it enough to write the patches on your behalf, at least,
not unless you are willing to hire someone to do that.  But at the same
time, no one has vetoed the idea of incorporating well-written patches.
 Patches speak louder than words; right now, your insistence on reviving
dead threads and complaining that no one is writing the patches is
rather annoying.  Quit beating a dead horse; if you want action, start
proposing patches rather than rants.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: having bash display real tabs for tab characters...

[Linda Walsh]

Eric Blake wrote:

On 07/11/2013 04:06 PM, Linda Walsh wrote:

Revisiting this...

Chet Ramey wrote:

On 4/25/13 8:45 AM, Greg Wooledge wrote:


If you think Bash is misbehaving, submit a patch, or wait for Chet to
comment on one of these threads.

I don't plan to comment or make any changes.  The demand for this
feature seems vanishingly small.



Bash could be leading edge in this area by supporting a tab-set command
(so bash, as a side effect, would continue to know where the cursor is
on the line).


This is YOUR itch, so YOU get to scratch it.  Apparently, no one else is
interested in it enough to write the patches on your behalf, at least,
not unless you are willing to hire someone to do that.  But at the same
time, no one has vetoed the idea of incorporating well-written patches.
 Patches speak louder than words; right now, your insistence on reviving
dead threads and complaining that no one is writing the patches is
rather annoying.  Quit beating a dead horse; if you want action, start
proposing patches rather than rants.


That's great!  I'll put it on my todo list.  I wasn't complaining that no
one was writing the patches.  I was opining that the perceived demand
of for the feature was underrated, in part due to broken utils that
don't implement support for settable tabs.

At least you are not like the perl people who insist that the language
not change in order to support 20 year old scripts w/o modification (though
they never have explained why they would be able to put "use "

to
"allow insecure wide links = ",

which doesn't tell you what they do and gives inaccurate security advice
which they seem to have no problem doing (mostly because they got reamed
when someone didn't know the consequences and made a bit stink about
samba being insecure due to having the feature, so it was disabled for
a few versions.  Basically, for sites that allow users to login to
their file server, it's not a security issue.  For those who don't
then if enabled with 'unix extensions', wide links allowed someone
to create links like local users can -- pointing at anything, which,
permission allowing, would allow it access to anything a local user
could point a link at.  Ohmy!  Like I said, for those that already
have their local users with logins on the server, it's not
a security issue, making the new name bogus.

Also, I don't think the horse was dead or well vetted in the first place.
it was brushed aside as being of vanishingly small size.
I was merely pointing out that miniature ponies are more popular
than one might think...(stretching your idea a bit...)...

Re: having bash display real tabs for tab characters...

[Linda Walsh]

Eric Blake wrote:

On 07/11/2013 04:06 PM, Linda Walsh wrote:

Revisiting this...

Chet Ramey wrote:

On 4/25/13 8:45 AM, Greg Wooledge wrote:


If you think Bash is misbehaving, submit a patch, or wait for Chet to
comment on one of these threads.

I don't plan to comment or make any changes.  The demand for this
feature seems vanishingly small.


It's not a feature to use simply echo output.  Bash implemented
a feature of tab expansion because tabs can be variably set.  While this
makes it's editing function consistent in terms of handling line wrap-around,
it doesn't make it consistent with the user's text as displayed on the screen
when they use 'echo' or 'printf' or display it with non-bash utils (cat
more-less, vim, perl...etc.

That bash does tab expansion is already an "added feature"
to compensate for terminals that have variable tabs.  I would characterize
the current tab-expansion feature as a hack to compensate for the difficulties
in implementing other solutions.  That doesn't mean I'm saying Chet should
try to fix it.  As you say, it's me that wants it to really work rather than
be patched over, so I should figure out what's needed to make it work.

Off hand, I'm thinking (besides keeping the current fixed expansion),
along the lines of 1st of 'descriptive' -- allowing a TABSET env var to hold
a current setting of tabs -- though that might be preceded by a simple ability
to set stops to something other than 8 which would likely serve 99% of the
people.  Secondly, bash could use the curses database to figure out if the
current terminal supported variable tabs; and/or simply try it.

My current bash script for dealing w/tabs, if invoked just tries
detecting the standard tab get/set function.  Only using
windows command.com window, I was able to get a term that DIDN'T work:

Ishtar:/> tty_tab
tty_tab: Term tabset ability not detected (out='' mycol='', promptlen=9)

But running on xfce's Terminal, konsole, xterm, and SecureCRT (in linux
mode) it prints out fixed tabstops... not sure what it would do if detected
variable, as I didn't implement that ability in it's set machinery.

I.e. some of this, beyond my needs, I likely wouldn't implement unless
there was demand.

FWIW, my existing tab detect and print (and set) script is attached.

If you run it on a term that supports tabs and reading their positions,
it should print something like:


tty_tab

tty_tab:- set tab stop to N
current value: tty_tab 8
(from 1, tabs skip to column: 9 17 25 33 41 49 57 65 73 80

(or for set @ 2):

tty_tab:- set tab stop to N
current value: tty_tab 2
(from 1, tabs skip to column: 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 
39 41 43 45 47 49 51 53 55 57 59 61 63 65 67 69 71 73 75 77 79 80



I take it that invitation for patches is still open
simplest would be fixed size w/env var setting...




#!/bin/bash  -u
#console_codes(4) man page... vt100/2 et && EMCA-48 standard
# Original author la walsh (2013) -- free to use and modify for personal use.

# v0.0.3- try to reduce tabcols to minimal set to reproduce.
# v0.0.2- set tabs for full terminal width (try to get term 
width)

shopt -s expand_aliases extglob
alias int='declare -i'
alias sub='function'
alias array='declare -a'
alias intArray='declare -ia'
alias P=printf

P -v clrallts  "\x1b[3g"
P -v sts   "\033H"
P -v cr"\013"
P -v cpr   "\x1b[6n"

sub getcols() {
local sttyout="$(stty size /dev/tty) & 2>/dev/null )  
  read  -sd R -r -t 2 ans &2
exit -1 
fi
}

sub do_help_n_display_curtabs () {  
  P "- set tab stop to N"
P "\r"
intArray diffs;
int last=1
int cur i
local eol=""
get_tabs && {
for ((i=0; i<${#tabs[@]}; ++i)); do
cur=${tabs[i]}
diffs[i]=cur-last
last=cur
done
intArray reverse_tabs_set=()
int prevtab=-1
for ((i=${#diffs[@]}-2; i>0; --i)); do
int thistab=${diffs[i]}
if ((thistab!= prevtab)) ;then 
reverse_tabs_set+=($thistab)
prevtab=thistab
fi
done
P "current value: tty_tab "
for ((i=${#reverse_tabs_set[@]}-1; i>=0; --i)); do
P "%d " "${reverse_tabs_set[i]}"
done
P "\r";
}
  get_tabs  && {
P "(from 1, tabs skip to column: "
P "%s " "${tabs[@]}"
P "\n"
  }
}

sub set_tabs () {
int max_col=${1:-80}## #columns on screen
int tabstop=${2:-"need a param for tabstop"}
int tab=$tabstop
str=""
int pos=0
P $clrallts ## reset old tabs
while ((++pos