bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bash not escaping escape sequences in directory names


From: konsolebox
Subject: Re: Bash not escaping escape sequences in directory names
Date: Tue, 25 Jan 2022 00:54:58 +0000

On Mon, Jan 24, 2022 at 11:40 PM Robert Elz <kre@munnari.oz.au> wrote:
> It was just that you replied to Andreas' message (the reply to my message)
> but didn't include him in the list of recipients, just me & the list.

Well I'm not sure what happened there.  I'm using Gmail and I always
click the "Reply to all" button.  I only make sure the list is
included in the recipients list and I don't really notice when others
aren't.

> That is exactly the issue.   Put \w (or \W) in your PS1, make a directory
> with a name containing escape sequences that affect the terminal, then
> cd into that directory.   The \w puts the directory name (uninterpreted)
> in the prompt, and sends it to the terminal, where it does whatever the
> escape sequences in it do.
>
> My solution to that is simply to avoid using the stupid \x PS1 escape
> sequences (aside from \\ \[ and \] which are different) at all - they're
> a sop to csh users that Korn put in his shell to try and make it more
> attractive to csh users (of all the things to worry about, this was about
> the least important), and then which bash copied.   They're not needed,
> everything useful that needs to be done can be done other ways, or is
> just static data that can be calculated in the .bashrc file (into variables
> which are exported) and forgotten.
>
> For \w (and \W) just write a "cd" function, which does 'command cd "$@"'
> and assuming that doesn't fail (if it does, there's nothing else to do),
> then sanitise $PWD however you like to make that happen, save the result
> in another variable, and use that variable in PS1.   That way you have
> total control over what is (or isn't) sent to your terminal, delegating
> none of the decision making to Chet.
>
> Similar things can handle everything else (or everything else anyone ever
> uses) and if something is too hard to handle that way, request a new
> BASH_xxx variable (or something) which produces the data that is needed.
> That would be reasonable, the \x nonsense (the PSx escapes) aren't.

Thanks for the details.  I at least agree with not using \w and \W
here if anyone wants to escape literal escape sequences, or wait till
bash adds a generous feature that escapes any valid terminal code.


-- 
konsolebox



reply via email to

[Prev in Thread] Current Thread [Next in Thread]