Re: shouldn't prompt printing be smarter?
Chet Ramey <[EMAIL PROTECTED]> wrote: > Fran Litterio wrote: >>> Also, creating an "option" to decide which behaviour should be followed >>> (current one or the one I propose) would make everyone happy >> >> It should be possible to code a value for PROMPT_COMMAND that sends >> the cursor position report escape sequence (for xterm this is >> "\033[6n"), learn the position of the cursor, and conditionally output >> a newline if the cursor is not in column 1. >> >> Some quick experimentation shows that this sequence of commands will >> do just that: > This is the right approach. In general, it's not possible for readline > to do this in a terminal-independent way -- termcap and terminfo do not > provide the appropriate capability. If you want to do this, you will > have to decide yourself which terminals to support. yes/no: since termcap doesn't have a standard, one can add capabilities if they're needed. ncurses's terminfo has a convention: # The System V Release 4 and XPG4 terminfo format defines ten string # capabilities for use by applications, In this file, we use # certain of these capabilities to describe functions which are not covered # by terminfo. The mapping is as follows: # # u9 terminal enquire string (equiv. to ANSI/ECMA-48 DA) # u8 terminal answerback description # u7 cursor position request (equiv. to VT100/ANSI/ECMA-48 DSR 6) # u6 cursor position report (equiv. to ANSI/ECMA-48 CPR) The feature won't work on some terminal types (Sun console for instance). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [Bug 103756] kate: syntax highlighting error: bash and escaped quotes
Carsten Lohrke wrote: Current bash.xml accepts (a), but not (b). The single qoute is the start of string highlight. It's also not just the backtick block, but the backtick block inside of a double quote string block - and vice versa. x="`echo \"'\\\"\"`"is valid My bash highlighter thinks this is invalid. So does my brain. However bash seems OK with it. Why, I wonder? Maybe I am not clear on the expansion rules in this instance. x=`echo \"'\\\"\"` isn't Ditto, except bash also (correctly IMO) doesn't like it. The other way around: x=`echo "'\""` is valid x="`echo "'\""`"isn't but both are highlighted as valid. That's odd, because all of the following are valid: echo "'\"" echo `echo "'\""` x="$(echo "'\"")" <-- this should be syntactically equivalent?! ...so this feels like a bug in bash. -- Matthew Vs lbh pna ernq guvf jvgubhg fbsgjner, lbh ner n FREVBHF areq! -- Nqncgrq sebz Znggurj Jva (ivz-qri znvyvat yvfg) ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: how does bash parse back-ticks, anyway? (was: [Bug 103756] kate: syntax highlighting error: bash and escaped quotes)
Since this is not really appropriate to the bug report, I am moving it exclusively to the lists. Please direct replies to kwrite-develkde.org and bug-bashgnu.org. Carsten Lohrke wrote: Matthew Woehlke wrote: Carsten Lohrke wrote: Current bash.xml accepts (a), but not (b). The single qoute is the start of string highlight. It's also not just the backtick block, but the backtick block inside of a double quote string block - and vice versa. x="`echo \"'\\\"\"`"is valid My bash highlighter thinks this is invalid. So does my brain. However bash seems OK with it. Why, I wonder? Maybe I am not clear on the expansion rules in this instance. x=`echo \"'\\\"\"` isn't Ditto, except bash also (correctly IMO) doesn't like it. The other way around: x=`echo "'\""` is valid x="`echo "'\""`"isn't but both are highlighted as valid. That's odd, because all of the following are valid: echo "'\"" echo `echo "'\""` x="$(echo "'\"")" <-- this should be syntactically equivalent?! ...so this feels like a bug in bash. Matthew, it's not a bug in bash, it's a feature. $(foo) and `foo` are not 100% equivalent. Read the command substitution paragraph in the bash man page. I did, and I saw that it talked about them being different, but I didn't understand *how* they were supposed to be different (besides, you've got some weirdnesses in there that look like they should/shouldn't work regardless of the back-ticks). In particular I fail to understand why whether or not there are quotes around the back-ticks should have any effect (which it clearly does). So until someone on bug-bash explains to me differently, I'm not convinced bash.xml is wrong. If nothing else, I'll stand by it being a bash bug, if only in the docs because they are not sufficiently clear. :-) -- Matthew Vs lbh pna ernq guvf jvgubhg fbsgjner, lbh ner n FREVBHF areq! -- Nqncgrq sebz Znggurj Jva (ivz-qri znvyvat yvfg) ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [Bug 103756] kate: syntax highlighting error: bash and escaped quotes
> > Current bash.xml accepts (a), but not (b). The single qoute is > > the start of string highlight. It's also not just the backtick > > block, but the backtick block inside of a double quote string > > block - and vice versa. First, be aware that `` in bash 3.1 was buggy, so you should upgrade to bash 3.2 rather than trying to figure out how the broken 3.1 parsing worked. > > > > x="`echo \"'\\\"\"`"is valid > > My bash highlighter thinks this is invalid. So does my brain. However > bash seems OK with it. Why, I wonder? Maybe I am not clear on the > expansion rules in this instance. > This is valid. According to POSIX, the double quoted string is terminated by the matching unquoted double quote, and within that string, the `` string is executed on the contents of the `` with the \ quotes before any $, `, ", \, and newline removed. So the result is that you are executing the command: `echo "'\""` Then, according to `` rules, $, `, and \ are special (but not "), so the subshell sees the command: echo "'\"" which is valid, and results in '" being assigned to x. > > x=`echo \"'\\\"\"` isn't > > Ditto, except bash also (correctly IMO) doesn't like it. Here, there is no surrounding "" to strip leading \ quotes special to "". So you are executing the command `echo \"'\\\"\"` and according to the rules of ``, the subshell sees: echo \"'\\"\" which indeed is a syntax error. > > > The other way around: > > > > x=`echo "'\""` is valid Valid. The subshell sees: echo "'\"" and x is assigned '" > > > > x="`echo "'\""`"isn't > > > > but both are highlighted as valid. Invalid. The "" ends at the first unquoted ", but that meant that you had an unpaired `, so bash is allowed to reject this. The difference was that by adding "" around ``, you have to also add \ escapes around characters special to "". > > That's odd, because all of the following are valid: > > echo "'\"" Valid. > echo `echo "'\""` Valid. The inner echo results in the three characters '", then the `` strips the newline, and since this was the expansion of ``, no further quoting is needed and the outer echo results in '" again. > x="$(echo "'\"")" <-- this should be syntactically equivalent?! $() has different rules than ``. Inside $(), any valid script is allowed, and by itself, echo "'\"" is a valid script. And inside "$()", the rules are explicit that the contents of the $() are not subject to normal "" escapes, but that the closing ) is found by a recursive parse. > > ...so this feels like a bug in bash. No, bash is correct. `` and $() are different, and the rules for "``" are different from "$()". And if it weren't for the fact that Solaris /bin/sh still doesn't understand $() which hampers its portable use, I would gladly ditch `` for the nicer semantics of $(). -- Eric Blake -- View this message in context: http://www.nabble.com/Re%3A--Bug-103756--kate%3A-syntax-highlighting-error%3A-bash-and-escaped-quotes-tf3507272.html#a9800902 Sent from the Gnu - Bash mailing list archive at Nabble.com. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [Bug 103756] kate: syntax highlighting error: bash and escaped quotes
Eric Blake-1 wrote: Current bash.xml accepts (a), but not (b). The single qoute is the start of string highlight. It's also not just the backtick block, but the backtick block inside of a double quote string block - and vice versa. First, be aware that `` in bash 3.1 was buggy, so you should upgrade to bash 3.2 rather than trying to figure out how the broken 3.1 parsing worked. x="`echo \"'\\\"\"`"is valid My bash highlighter thinks this is invalid. So does my brain. However bash seems OK with it. Why, I wonder? Maybe I am not clear on the expansion rules in this instance. This is valid. According to POSIX, the double quoted string is terminated by the matching unquoted double quote, and within that string, the `` string is executed on the contents of the `` with the \ quotes before any $, `, ", \, and newline removed. So the result is that you are executing the command: `echo "'\""` Then, according to `` rules, $, `, and \ are special (but not "), so the subshell sees the command: echo "'\"" which is valid, and results in '" being assigned to x. x=`echo \"'\\\"\"` isn't Ditto, except bash also (correctly IMO) doesn't like it. Here, there is no surrounding "" to strip leading \ quotes special to "". So you are executing the command `echo \"'\\\"\"` and according to the rules of ``, the subshell sees: echo \"'\\"\" which indeed is a syntax error. The other way around: x=`echo "'\""` is valid Valid. The subshell sees: echo "'\"" and x is assigned '" x="`echo "'\""`"isn't but both are highlighted as valid. Invalid. The "" ends at the first unquoted ", but that meant that you had an unpaired `, so bash is allowed to reject this. The difference was that by adding "" around ``, you have to also add \ escapes around characters special to "". That's odd, because all of the following are valid: echo "'\"" Valid. echo `echo "'\""` Valid. The inner echo results in the three characters '", then the `` strips the newline, and since this was the expansion of ``, no further quoting is needed and the outer echo results in '" again. x="$(echo "'\"")" <-- this should be syntactically equivalent?! $() has different rules than ``. Inside $(), any valid script is allowed, and by itself, echo "'\"" is a valid script. And inside "$()", the rules are explicit that the contents of the $() are not subject to normal "" escapes, but that the closing ) is found by a recursive parse. ...so this feels like a bug in bash. No, bash is correct. `` and $() are different, and the rules for "``" are different from "$()". And if it weren't for the fact that Solaris /bin/sh still doesn't understand $() which hampers its portable use, I would gladly ditch `` for the nicer semantics of $(). Yike, that's bizzarre... so essentially what you are saying is that the semantics of a `` expression differ based on whether or not it occurs within quotes? That definately strikes me as unintuitive... and it's not going to make handling the issue pretty, no, not at all. :-( I still think the doc could be clearer on this issue. -- Matthew Vs lbh pna ernq guvf jvgubhg fbsgjner, lbh ner n FREVBHF areq! -- Nqncgrq sebz Znggurj Jva (ivz-qri znvyvat yvfg) ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: how does bash parse back-ticks, anyway?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Matthew Woehlke on 4/2/2007 5:09 PM: >> Matthew, it's not a bug in bash, it's a feature. $(foo) and `foo` >> are not 100% equivalent. Read the command substitution paragraph >> in the bash man page. > > I did, and I saw that it talked about them being different, but I didn't > understand *how* they were supposed to be different (besides, you've got > some weirdnesses in there that look like they should/shouldn't work > regardless of the back-ticks). In particular I fail to understand why > whether or not there are quotes around the back-ticks should have any > effect (which it clearly does). So until someone on bug-bash explains to > me differently, I'm not convinced bash.xml is wrong. Read the POSIX rationale: http://www.opengroup.org/onlinepubs/009695399/xrat/xcu_chap02.html | The "$()" form of command substitution solves a problem of inconsistent | behavior when using backquotes. For example: | | Command Output | echo '\$x' \$x | echo `echo '\$x'` $x | echo $(echo '\$x') \$x | | Additionally, the backquoted syntax has historical restrictions on the | contents of the embedded command. While the newer "$()" form can process | any kind of valid embedded script, the backquoted form cannot handle | some valid scripts that include backquotes. For example, these otherwise | valid embedded scripts do not work in the left column, but do work on | the right: | | echo ` echo $( | cat <<\eof cat <<\eof | a here-doc with ` a here-doc with ) | eofeof | ` ) | | echo ` echo $( | echo abc # a comment with `echo abc # a comment with ) | ` ) | | echo ` echo $( | echo '`' echo ')' | ` ) | | Because of these inconsistent behaviors, the backquoted variety of | command substitution is not recommended for new applications that nest | command substitutions or attempt to embed complex scripts. > > If nothing else, I'll stand by it being a bash bug, if only in the docs > because they are not sufficiently clear. :-) > The POSIX rules here are that when parsing plain ``, \ quotes only $, `, and \. When surrounding `` inside "", the escape characters special to "" are removed prior to handling ``, which means that you have to additionally escape $, `, ", \, and newline to account for the added level of "" parsing. It is this additional level of escaping which applies only to `` that makes "``" hard to parse, and which does not apply to $() parsing. And as the autoconf manual documents, there is no portable way to include a double-quoted string inside a "``" sequence. - -- 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 iD8DBQFGEbfH84KuGfSFAYARAokDAJ90H2gp52xiZpxYUMKTCgL7uSeRigCcDpvB m2Ly3pW4oFTE/B0AvihPcK4= =4kbd -END PGP SIGNATURE- ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
inconsistent output for cd
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.15-13/src/bash-3.2
-I/home/eblake/bash-3.2.15-13/src/bash-3.2/include
-I/home/eblake/bash-3.2.15-13/src/bash-3.2/lib -O2 -pipe
uname output: CYGWIN_NT-5.1 nycutbalil 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: 15
Release Status: release
Description:
Sometimes cd echos the new directory, sometimes it doesn't. This makes
picking up a new directory in an overridden cd function painful:
cd () {
local oldd=$(pwd)
local newd=$(command cd "$@" 2>/dev/null 1>&2 && pwd 2>/dev/null)
# echo oldd="<$oldd>"
# echo newd="<$newd>"
if [[ $newd == "" ]]; then
echo "cd $* failed" 1>&2
elif [[ $oldd == $newd ]]; then
echo "cd $* - no change" 1>&2
else
# do extra cd processing here
command cd "$@" 2>/dev/null 1>&2
# do extra cd processing here
fi
}
In the assignment of newd, curiously, we get either one line or two!
newd should be just the new directory (the result of running built-in
cd in a subshell) but since it sometimes outputs a result (which seems
to bypass the output redirection), newd may end up with two separate
directories in two lines.
It seems like this extra output only occurs when CDPATH is used for the
cd operation. Also, popd and pushd also have similarly inconvenient
outputs. None of this is documented in the manual, and there appear to
be no options at all to turn this superfluous output off.
Repeat-By:
Try the above function, with the commented lines uncommented. Use it
to change to a directory in the CDPATH. Check the newd=... output.
Fix:
Don't use CDPATH! But that's a shame...
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
