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: Robert Elz
Subject: Re: Bash not escaping escape sequences in directory names
Date: Tue, 25 Jan 2022 06:39:02 +0700

    Date:        Mon, 24 Jan 2022 23:00:38 +0000
    From:        konsolebox <konsolebox@gmail.com>
    Message-ID:  
<CAJnmqwa5WO-O2Ph2XEtci-frUYhK22faPVWSL-qe-516RdQoAA@mail.gmail.com>


  | It's meant to be a general reply to the thread.

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.

  | If the code is in no way interpreted by bash and literally just sent to the
  | terminal

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.

kre




reply via email to

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