[Ann] BashSupport 0.5

Hello again!

Thanks for being so quick to update the BASH plug-in.

I noticed that in the Plugin Manager the long description block mentions 0.4, though the version ID below it is 0.5.

Here are the latest little glitches I've noticed as I just opened one after another of my many scripts:

1) Multi-line quoted strings:

jtmplUsage="# Usage:
#   jtmpl [ [ options ] classOrInterfaceName ] [ ... ]
#
# Options:
#   -i              Produce a java interface
#   -c              Produce a java class
#   -p package      Specify the package in which the
#                     new class or interface resides
#   -e base         Specify base class or interface to extend
#                     (comma-separated list; one only for classes)
#   -m interface    Specify implemented interfaces (comma-separated)
#   -I interface    Alternate option code for -m
#   -f              Allow overwrite of already exsisting output files
#   --help          Show this usage summary
#
# Environment:
#   JTMPL_INTF   Header file for interfaces
#   JTMPL_CLASS   Header file for classes
"


2) Repeated exceptions

I have a longish script that when opened leads to a seemingly unending series of exceptions. For some reason, there's a considerable delay between closing the exception window and the appearance of the next one. There does not appear to be high CPU usage during the interval. I've attached the stack trace (the Blame button doesn't work for 3rd-party plug-ins, I guess) and the BASH script that triggered the problem (two scripts did this, so there are two pairs of attached files).

3) Escaped quotes within quoted strings

    for arg; do
        echo -n " \"$(echo "$arg" |sed -e 's/"/\\"/g')\""
    done >>.pjrc



Randall Schulz

Hello,
thank you for your feedback.

1) Multi-line quoted strings:

Fixed for the next update. I didn't even know that this was possible :)

>

2) Repeated exceptions

Thanks, the exceptions are fixed. The scripts also showed some parsing issues which I have to fix. Thanks for the files.

3) Escaped quotes within quoted strings
for arg; do
echo -n " \"$(echo "$arg" |sed -e 's/"/
"/g')\""
done >>.pjrc

That's a weird one :)
The problem isn't the escaped string but the nested $() which contains another string. Atm the parser sees
" \"$(echo ", then $arg, then " |sed -e 's/", then /
and then "/g')\"" . Additionally, the escaping of
is not parsed correctly.

I think Bash does String nesting:
export z=1; echo "$(export z=2; echo "$(echo "$z")")"
prints 2 - which means strings are nested, I think. Strings inside of $() are seen as seperate string even though it's embedded in
another string.

Nested strings, I don't know another language which has this great feature :(
To fix this I need to fix up the lexer so it won't be in the next update.
I guess there are more strange things hidden in the past of Bash's history...

Wallaby

Guest wrote:

...

3) Escaped quotes within quoted strings
   for arg; do
       echo -n " \"$(echo "$arg" |sed -e 's/"/
"/g')\""
   done >>.pjrc

That's a weird one :)
The problem isn't the escaped string but the nested $() which contains another string. Atm the parser sees
" \"$(echo ", then $arg, then " |sed -e 's/", then /
and then "/g')\"" . Additionally, the escaping of
is not parsed correctly.

I think Bash does String nesting:
     export z=1; echo "$(export z=2; echo "$(echo "$z")")"
prints 2 - which means strings are nested, I think. Strings inside of $() are seen as seperate string even though it's embedded in
another string.

Nested strings, I don't know another language which has this great feature :(
To fix this I need to fix up the lexer so it won't be in the next update.
I guess there are more strange things hidden in the past of Bash's history...

Wallaby

It is true that $( ... ) constructs nest and that within a $( ... ) that is nested within another, an entirely new parsing context starts and as with other more common command parsing cases, the initial state is not "in string" even if the $( ... ) (inner or outer) are themselves within string quotes.

I always use $( ... ) instead of `...` because it's a lot easier to read, Vim's paren matching works and nesting is sensible (with or without quote marks).

BASH is certainly a odd bird in the syntax department and that's largely a result of a long and tortured history. You should have seen the shell in v7 Unix!


Randall Schulz