Re: How to show path with backslash '\' in it in the prompt?
On 07/11/2010 05:07 AM, Chet Ramey wrote:
On 7/10/10 11:00 PM, Peng Yu wrote:
On Sat, Jul 10, 2010 at 9:52 PM, Chet Ramey wrote:
On 7/10/10 9:57 PM, Peng Yu wrote:
Hi,
I have a directory named '\E' (two letters, rather than a single
special character). I have the following $PS1 variable.
$ echo $PS1
${debian_chroot:+($debian_chroot)}...@\h:\w\$
When my current directory is '\E', the prompt shows a special
character (I think that it should be the special character '\E'). I'm
wondering if there is a way to change $PS1 to show two characters '\'
and 'E'.
I don't get this behavior with bash-4.1. It may be PROMPT_COMMAND
that is messing up your display.
No. I don't think that it is because of PROMPT_COMMAND. I set
PROMPT_COMMAND to the following command. But the prompt doens't
change. It only print an additional line whenever I run a command.
export PROMPT_COMMAND=echo
OK. I still can't reproduce it with bash-4.1.
I can reproduce it.
[rra...@dhcp-lab-170 tmp]$ mkdir '\E'
[rra...@dhcp-lab-170 tmp]$ cd \\E/
]0;rra...@dhcp-lab-170:~/tmp/ra...@dhcp-lab-170 \E]$
]0;rra...@dhcp-lab-170:~/tmp/ra...@dhcp-lab-170 \E]$ set -x
++ echo -ne '\033]0;rra...@dhcp-lab-170:~/tmp/\E'
[rra...@dhcp-lab-170 \E]$
]0;rra...@dhcp-lab-170:~/tmp/ra...@dhcp-lab-170 \E]$ echo $BASH_VERSION
4.1.7(1)-release
Tried with gnome-terminal (gnome-terminal-2.30.1-1.fc13.x86_64) -
reproducable
with xterm (xterm-261-2.fc13.x86_64) - not reproducable
echo $PS1
[...@\h \W]\$
echo $PROMPT_COMMAND
echo -ne "\033]0;${us...@${hostname%%.*}:${PWD/#$HOME/~}"; echo -ne "\007"
RR
Re: How to show path with backslash '\' in it in the prompt?
On 7/21/10 7:55 AM, Roman Rakus wrote:
> I can reproduce it.
Of course you can. You asked to see it.
> [rra...@dhcp-lab-170 tmp]$ mkdir '\E'
> [rra...@dhcp-lab-170 tmp]$ cd \\E/
> ]0;rra...@dhcp-lab-170:~/tmp/ra...@dhcp-lab-170 \E]$
> ]0;rra...@dhcp-lab-170:~/tmp/ra...@dhcp-lab-170 \E]$ set -x
> ++ echo -ne '\033]0;rra...@dhcp-lab-170:~/tmp/\E'
> [rra...@dhcp-lab-170 \E]$
> ]0;rra...@dhcp-lab-170:~/tmp/ra...@dhcp-lab-170 \E]$ echo $BASH_VERSION
> 4.1.7(1)-release
>
> Tried with gnome-terminal (gnome-terminal-2.30.1-1.fc13.x86_64) -
> reproducable
> with xterm (xterm-261-2.fc13.x86_64) - not reproducable
>
> echo $PS1
> [...@\h \W]\$
> echo $PROMPT_COMMAND
> echo -ne "\033]0;${us...@${hostname%%.*}:${PWD/#$HOME/~}"; echo -ne "\007"
Consider what happens when you ask echo to expand escape sequences and
give it an argument containing arbitrary backslash-escapes, which it will
happily expand and mess up your terminal control sequence. The
uninterpreted portion will be output to the terminal.
I'm not sure why people don't use printf or $'' instead of echo.
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/
words in COMPWORDS vs. words in COMPREPLY
I'm trying to learn how bash completion works, so that I can
write completion functions for some utilities.
As an experiment, I wrote the following trivial completion. It
is intended to report that the completions for the current word
are exactly the contents of the current word:
_test () {
COMPREPLY=(${COMP_WORDS[COMP_CWORD]})
}
complete -F _test test
I expected that, with the above, typing "test", followed by a
word, followed by , would cause bash just to insert a space.
This is often what happens, but I've found some exceptions that I
do not yet understand. For example, consider the following:
test x=
When I press , I expected this to expand to:
test x=
followed by a space.
With Debian's bash 4.1-3 (on which bash --version reports
"version 4.1.5(1)-release"), this actually expands as:
test x==
followed by a space.
With Debian's bash 3.2-4 ("bash 3.2.39(1)-release"), this expands
as:
test x=x=
followed by a space.
Can anyone explain to me what bash is doing here? I am trying to
write completion code for a utility that accepts some arguments
of the form "key1=value,key2=value,...", and this seemingly odd
behavior is making life difficult.
Thanks,
Ben.
--
Ben Pfaff
http://benpfaff.org
Re: access(2) shouldn't be used with test(1)
There are times when adherence to historical bugs is a reminder of the great flaw of the standards process. Broken standards should be fixable That said...um yeah...practicality indicates steering around broken POSIX functionality... Eric Blake wrote: On 07/20/2010 03:22 PM, Garrett Cooper wrote: Correct. Sounds like a bug to me if a file isn't executable, I don't care how "super" you are -- permission won't make a text file executable! ;-) Yes, but POSIX says that it's allowed to be broken based on past behavior, and FreeBSD just says "don't use access, act on the file", which means that access on FreeBSD is only really useful for F_OK, but I can get that from open/fstat/whatever. POSIX says: http://www.opengroup.org/onlinepubs/9699919799/functions/access.html Normative: "If any access permissions are checked, each shall be checked individually, as described in XBD File Access Permissions , except that where that description refers to execute permission for a process with appropriate privileges, an implementation may indicate success for X_OK even if execute permission is not granted to any user." Descriptive: "In early proposals, some inadequacies in the access() function led to the creation of an eaccess() function because: 1. Historical implementations of access() do not test file access correctly when the process' real user ID is superuser. In particular, they always return zero when testing execute permissions without regard to whether the file is executable. 2. The superuser has complete access to all files on a system. As a consequence, programs started by the superuser and switched to the effective user ID with lesser privileges cannot use access() to test their file access permissions. However, the historical model of eaccess() does not resolve problem (1), so this volume of POSIX.1-2008 now allows access() to behave in the desired way because several implementations have corrected the problem. It was also argued that problem (2) is more easily solved by using open(), chdir(), or one of the exec functions as appropriate and responding to the error, rather than creating a new function that would not be as reliable. Therefore, eaccess() is not included in this volume of POSIX.1-2008. The sentence concerning appropriate privileges and execute permission bits reflects the two possibilities implemented by historical implementations when checking superuser access for X_OK. New implementations are discouraged from returning X_OK unless at least one execution permission bit is set." Thus, access(2) _may_ say X_OK for the superuser, regardless of whether stat()/ACL say anyone can execute, based on historical behavior, although this historical behavior is frowned upon. However, nowhere does POSIX allow R_OK or W_OK to return true if stat()/ACL don't grant read/write privileges to someone, and as long as access() is doing the permission check for rw, it shouldn't be too hard to patch it to also do the permission check for x. So, if FreeBSD is poor QoI because of POSIX, it had better only be for 'test -x' and not for 'test -r' or 'test -w'. Meanwhile, POSIX says that access(a,b) and faccessat(AT_FDCWD,a,b,0) must be identical in behavior.
document $MAIL for Maildir users
man page says MAIL If this parameter is set to a file name and the MAILPATH variable is not set, bash informs the user of the arrival of mail in the specified file. OK, but also mention one can set it to a directory. And say that MAIL=$HOME/Maildir/ is what Maildir users should use.
