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 g
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 term
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"
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.
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
directo
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'