Re: inconsistent output for cd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Tony Balinski on 4/3/2007 11:49 AM: > > Running bash on Cygwin (taken from Cygwin): ... > Curiously, under the same conditions on a Red Hat Linux box: Why didn't you say so in the first place? If this behavior only occurs on cygwin, then it is a bug in either cygwin or the bash port of cygwin, and you should have reported it to the cygwin mailing list, rather than forcing upstream to come up with the workaround. At any rate, since I maintain the cygwin port of bash, I'll look into it; I can certainly reproduce it, so it looks like there is a problem with file redirection on builtins inside command substitution on cygwin. $ pwd /home/eblake/bash $ command cd bash /home/eblake/bash $ command cd bash 2>/dev/null 1>&2 $ echo $(command cd bash 2>/dev/null 1>&2) /home/eblake/bash $ - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGE6CP84KuGfSFAYARAmgUAJ4lpL/1UqDmnuRuNXGopmhRaesf4gCgvl9g DTVlt4U5TTHAUVJs0zxFAyA= =yVCB -END PGP SIGNATURE- ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
type -p return status is 0 if alias found
Configuration Information [Automatically generated, do not change]: Machine: i686 OS: cygwin Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='i686-pc-cygwin' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -DRECYCLES_PIDS -I. -I/home/eblake/bash-3.2.9-11/src/bash-3.2 -I/home/eblake/bash-3.2.9-11/src/bash-3.2/include -I/home/eblake/bash-3.2.9-11/src/bash-3.2/lib -O2 -pipe uname output: CYGWIN_NT-5.1 aa-04991 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin Machine Type: i686-pc-cygwin Bash Version: 3.2 Patch Level: 9 Release Status: release Description: "type -p CMD" normally has a non-zero return status if CMD is not found. But if CMD is an alias, the return status is zero even though nothing is printed to stdout. Repeat-By: $ type -p fred; echo $? 1 $ alias fred= $ type -p fred; echo $? 0 ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: type -p return status is 0 if alias found
On Tuesday 03 April 2007, [EMAIL PROTECTED] wrote: >"type -p CMD" normally has a non-zero return status if CMD is not > found. But if CMD is an alias, the return status is zero even though > nothing is printed to stdout. by definition, this is how -p is supposed to work ... my guess is you want -P -mike pgpNXlUeFGo1E.pgp Description: PGP signature ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
RE: type -p return status is 0 if alias found
Thanks for your reply, Mike! Here's what I'm reading in the man page: type [-aftpP] name [name ...] With no options, indicate how each name would be interpreted if used as a command name. If the -t option is used, type prints a string which is one of alias, keyword, function, builtin, or file if name is an alias, shell reserved word, function, builtin, or disk file, respectively. If the name is not found, then nothing is printed, and an exit status of false is returned. If the -p option is used, type either returns the name of the disk file that would be executed if name were speci- fied as a command name, or nothing if ``type -t name'' would not return file. The -P option forces a PATH search for each name, even if ``type -t name'' would not return file. If a command is hashed, -p and -P print the hashed value, not necessarily the file that appears first in PATH. If the -a option is used, type prints all of the places that contain an executable named name. This includes aliases and functions, if and only if the -p option is not also used. The table of hashed commands is not consulted when using -a. The -f option suppresses shell func- tion lookup, as with the command builtin. type returns true if any of the arguments are found, false if none are found. I can see that you're interpreting the last sentence to mean: type -p NAME found NAME and therefore it returned true. But since it was not a "file" (according to type -t NAME), then it didn't print anything. Maybe this is the only distinction between -p and -P (it's hard to tell because of the way it's worded)? If so, then it would be clearer to state it directly with something like: The -P option is like the -p option. However the -P option returns true iff ``type -t name'' would print ``file'', whereas the -p option returns true iff ``type -t name'' would return true. Is there any other distinction between -p and -P? It certainly surprised me to see that -p printed nothing but returned true. Was that the reason -P was created -- to bring the return value in line with the output? Thanks! -- John Wiersba > -Original Message- > From: Mike Frysinger [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 04, 2007 12:25 PM > To: bug-bash@gnu.org > Cc: Wiersba, John (TH USA) > Subject: Re: type -p return status is 0 if alias found > > On Tuesday 03 April 2007, [EMAIL PROTECTED] wrote: > >"type -p CMD" normally has a non-zero return status if CMD is not > > found. But if CMD is an alias, the return status is zero > even though > > nothing is printed to stdout. > > by definition, this is how -p is supposed to work ... my > guess is you want -P > -mike > ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
readline vs. literal \1 and \2
A readline question recently came up on the cygwin list. The root cause of the
problem is that the cmd.com terminal accepts the sequence "\001" as a printing
character for a hollow smiley face, and the sequence "\002" as a solid smiley
face. But readline is also documented as using \1 and \2 as the invisible
sequence delimiters (so it can emit terminal escape sequences without getting
confused as to screen position).
The original bug reporter was confused when they had two smiley faces in the
prompt of lftp, a program linked against readline 5.2, and I traced it to the
fact that the user set up lftp to call
readline("\001\001\027]0;title\a\001\002> ");
instead of
readline("\001\027]0;title\a\002> ");
lftp was blindly copying the fact that in bash's parse.y, decode_prompt_string
turns \[ in PS1 into \001\001, but failed to realize that between that point
and when bash actually called readline, it also stripped the extra \001 in
expand_prompt_string(). On most terminals (such as xterm or rxvt), this
results in two invisible \001 characters being printed, but the terminal thinks
they are non-printing, so no overall damage results. But on cmd.com, the inner
two \001 characters printed, which a) showed up as unwanted smileys, and b)
messed up readline redisplay since supposedly-invisible characters actually
occupied display width.
So the original bug is fixed by changing lftp to quit emitting the two spurious
\001 when they use readline.
However, it does raise a question pertinent to this list. While the original
user found the smiley printed for \001 unwanted, I can imagine a scenario where
a user familiar with their cmd.com terminal wants to make readline
INTENTIONALLY print a smiley, without getting readline redisplay messed up.
Similarly, it is feasible to imagine a terminal that supports an escape
sequence where it is desirable to feed a literal \002 as part of the escape
sequence. Currently, readline makes it possible only to print invisible \001
and visible \002. Is it worth improving readline to add an escape sequence
such that it is ALSO possible to intentionally print a visible \001 or
invisible \002? And if this change to readline is made, then should bash's
decode_prompt_string special case PS1='\001' to result in a literal \001,
rather than the current behavior of treating it as a synonym for PS1='\['?
--
Eric Blake
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
