Matthew Woehlke wrote:
> True, but... not really relevant. The original question deals with how
> kate should highlight this, ergo we need to know if the current behavior
> is intended. Using a syntax that doesn't confuse kate is a workaround,
> not a fix. (Also, if you'd read the bug report,
Eric Blake wrote:
On 06/07/2010 04:47 PM, Matthew Woehlke wrote:
But this does not:
$ echo "`echo \"you don\'t say\"`"
you don\'t say
\' is not special inside ``. If it is not special, then the \ is
preserved on to the nested command. Bash's behavior matches POSIX here.
Right; w.r.t. t
On 06/07/2010 04:47 PM, Matthew Woehlke wrote:
> But this does not:
> $ echo "`echo \"you don\'t say\"`"
> you don\'t say
\' is not special inside ``. If it is not special, then the \ is
preserved on to the nested command. Bash's behavior matches POSIX here.
>
> I expected:
> "you don't sa
On 06/07/2010 04:56 PM, Bob Proulx wrote:
> Matthew Woehlke wrote:
>> How should bash interpret escapes in constructs like "`...`"?
>
> The quoting rules for backticks are complex enough that the entire
> construct has long been replaced with a completely different one. I
> strongly suggest that
Bob Proulx wrote:
Matthew Woehlke wrote:
How should bash interpret escapes in constructs like "`...`"?
The quoting rules for backticks are complex enough that the entire
construct has long been replaced with a completely different one. I
strongly suggest that instead of struggling to get the
Matthew Woehlke wrote:
> How should bash interpret escapes in constructs like "`...`"?
The quoting rules for backticks are complex enough that the entire
construct has long been replaced with a completely different one. I
strongly suggest that instead of struggling to get the backtick syntax
quot
On 06/07/2010 02:38 PM, Chet Ramey wrote:
> I bet this is the kernel killing bash when the stack size resource limit
> is exceeded, not anything bash is doing or can catch.
To the contrary, it is possible to use the GPL libsigsegv to catch stack
overflow and exit with a clean error message instead
(See also https://bugs.kde.org/show_bug.cgi?id=237675)
How should bash interpret escapes in constructs like "`...`"?
For example, this do what I would expect:
$ echo "`echo "you don't say"`"
you don't say
(That is, the contents in ``'s are parsed independent of any other
context, except t
On 6/7/10 1:19 AM, Jan Schampera wrote:
> Chet Ramey wrote:
>
>> How about a stack traceback?
>
> I'm so sorry, I thought this was clear and easy to reproduce/verify.
>
> I'm using this to generate the script. The number of commands varies
> between shell versions (and likely other platform stuf
On Sat, Jun 05, 2010 at 12:10:34PM +, Jay K wrote:
> extern int vsnprintf __P((char *, size_t, const char *, ...))
> __attribute__((__format__ (printf, 3, 4)));
> ---^
> cc: Error: ./printf.def, line 175: In this declaration, the type of
> "vsnprintf" is not compatible with the type o
> Chet Ramey wrote:
>
> > How about a stack traceback?
>
> I'm so sorry, I thought this was clear and easy to reproduce/verify.
Sure, but you've already done the work. :-)
I'll take a look. Thanks for the report.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
11 matches
Mail list logo
