in error messages, do not output raw non-printable characters to the terminal

[Vincent Lefevre]

In error messages, raw non-printable characters from arguments should
not be output without transformation, at least if this is on a terminal.
If stderr has been redirected, this is more a matter of choice.

An example: type "cd /^M" where ^M is a CR character (e.g. obtained by
typing ^V ^M). One gets on the terminal:

: No such file or directory

which is not very informative. This leads to this kind of questions:

  
http://unix.stackexchange.com/questions/154408/cant-cd-to-home-user-when-sourcing-a-script

IMHO, in this case, bash should do like zsh, which replaces the CR
character by the character sequence "^M".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: in error messages, do not output raw non-printable characters to the terminal

[Ryan Cunningham]

Maybe BASH should instead output "$'\r'" in the error message in your case.

-- 
Sent from my iPad

> On Sep 10, 2014, at 1:58 AM, Vincent Lefevre  wrote:
> 
> In error messages, raw non-printable characters from arguments should
> not be output without transformation, at least if this is on a terminal.
> If stderr has been redirected, this is more a matter of choice.
> 
> An example: type "cd /^M" where ^M is a CR character (e.g. obtained by
> typing ^V ^M). One gets on the terminal:
> 
> : No such file or directory
> 
> which is not very informative. This leads to this kind of questions:
> 
>  
> http://unix.stackexchange.com/questions/154408/cant-cd-to-home-user-when-sourcing-a-script
> 
> IMHO, in this case, bash should do like zsh, which replaces the CR
> character by the character sequence "^M".
> 
> -- 
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> 

Re: in error messages, do not output raw non-printable characters to the terminal

[Steve Simmons]

On Sep 10, 2014, at 4:58 AM, Vincent Lefevre  wrote:

> In error messages, raw non-printable characters from arguments should
> not be output without transformation, at least if this is on a terminal.
> If stderr has been redirected, this is more a matter of choice.
> 
> An example: type "cd /^M" where ^M is a CR character (e.g. obtained by
> typing ^V ^M). One gets on the terminal:
> 
> : No such file or directory
> 
> which is not very informative...

One of many arguments why command error errors should be handled, and
why interpreted data in messages should be surrounded by quotes (not
quoted, but surrounded by quotes). As an example, this is much more
effective for ugly values of $LOG like control-M or " dir name":

   # Empty the log directory 

   if ! cd "$LOG" ; then
   echo "Directory '$LOG' doesn't exist or not accessible, halting."
   exit 1
   fi
   # take actions here...
   rm *

is a helluva lot more sensible than

   cd $LOG
   # take actions here...
   rm *

> IMHO, in this case, bash should do like zsh, which replaces the CR
> character by the character sequence "^M".

This doesn't seem like a good idea. At our site it leads our zsh users
to send us complaints that they don't have a file with the two-character
name ^M.

Beyond there, there are several drawbacks. I'd hate to see the built-in
echo diverge from system /bin/echo (or diverge further, as the case may
be). It would also break this current behavior:

   CLEAR_SCREEN=$(tput clear)
   echo $CLEAR_SCREEN

By comparison, checking returns from commands like cd and surrounding
echoed/printed parameters by quotes will work for pretty much all legacy
bash/ksh/sh shells, maybe zsh as well. 

I believe that perl has some sort of quote function that takes a string
with non-printable chars and converts them to ^M, \033, etc. That, used
judiciously, strikes me as more sensible. Of course, you'd still have to
use and quote it properly. For $LOG values like ' dir name' or control-M
or not defined, consider the ways this can go wrong:

   if ! cd $LOG ; then
  echo Directory $(quoteme $LOG) does not exist or not accessible.
  exit 1
   fi
   rm *

vs this:

   if ! cd "$LOG" ; then
  print "Directory '%s' does not exist.\n" "$(quoteme "$LOG")"
  exit 1
   fi
   rm *

Steve

Re: in error messages, do not output raw non-printable characters to the terminal

[Ángel González]

Steve Simmons wrote:
> > IMHO, in this case, bash should do like zsh, which replaces the CR
> > character by the character sequence "^M".
> 
> This doesn't seem like a good idea. At our site it leads our zsh users
> to send us complaints that they don't have a file with the two-character
> name ^M.
> 
> Beyond there, there are several drawbacks. I'd hate to see the built-in
> echo diverge from system /bin/echo (or diverge further, as the case may
> be). It would also break this current behavior (snip)

Note that Vicent is talking about replacing them *in error messages*.
echo should be left as-is.

I agree with Ryan that it should output $'\r'

a) It's more consistent, as that's already output on other errors:

> $ ^M
> bash: $'\r': command not found

> cd ^M
> : No such file or directory


b) $'\r' is an appropiate input, as opposed to manually retyping ^M (hopefully 
this should help when people comes confused about not having such file)

Re: in error messages, do not output raw non-printable characters to the terminal

[Greg Wooledge]

On Wed, Sep 10, 2014 at 01:32:18PM -0400, Steve Simmons wrote:
> is a helluva lot more sensible than
> 
>cd $LOG
># take actions here...
>rm *

Oh dear gods.  That's madness.  Never EVER do that.  If the cd command
fails for any reason, you will remove all the files in the wrong
directory.

cd "$LOG" && rm -- *  # This is much, much safer.

Or if there are several actions that all need to be done in the $LOG
directory, wrap it in something you can escape from, like a function:

cleanup() {
cd "$LOG" || return
# other actions
rm -- *
}

Re: Terminal messed up after exiting bash

[Chet Ramey]

On 9/8/14, 4:17 AM, Jan Rome wrote:
> Hello,
> 
> I'd like to report an obscure bug I came across in pfsense which runs on
> top of FreeBSD.
> 
> If I run a bash script in which I have
> 
> read -r -n1 -p "prompt: "
> 
> and instead of providing input, i ctrl-c the script,
> 
> the ash shell doesn't recover the terminal properly; backspace echos ^? and
> the only way to delete characters is to hold shift and press backspace.
> Also,  if I use the -s switch for the read command in the bash script, the
> problem gets even worse with the cursor not moving anymore as I type and
> the text I type not being visible at all.

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/