Warning (HTML included to show prog shipped w/syntax highlighting).
When I have the construct, in 4.1: 1 #!/bin/bash 2 30 31 # trace control for subs 32 declare -ix Allow_Trace=$((( 33 _D_LowLevel | 34 _D_Provides | 35 _D_ 36 ))) 37 38 declare -ix Trace_off=$((( 39 _D_ 40 ))) 41 42 # for setting a local '_Debug' flag in a routine 43 declare -ix Debug=$((( 44 _D_ 45 ))) 46 47 907 # vim: ts=2 sw=2 fdm=marker nofen The syntax highligher doesn't like my ) brace. If I put a space after $( and before th final ), then the error goes away, but it changes the semantics of the statment (one does an arith cal, and reurns value, but with spaces, it does the arith and returns the status of the of wheither or not the 'calc' returned 0 (fail) or 1(pass). For hosethat want to complain about HTML, bing used on vim llist -- - just ignore the post.. Is this fixable???
Re: echo "enhancement" leads to confused legacy script tools...
Henrik Nordstrom wrote: lör 2006-03-18 klockan 14:15 -0800 skrev Linda W: Bash added the "feature" to allow dropping of the leading "0", accepting strings: "\0nnn", "\nnn", and "\xHH". I'm guessing that most bash users run in a shell that has expansion turned off by default or this would have come up before. the xpg_echo bash option.. Lets see what this does to configure shall we.. oh, yes it fails miserably with this bash option set. please send this to the autoconf maintainers as well. Probably they can add a rule detecting this kind of systems and falling back on an alternative somewhat slower echo method.. Regards Henrik I believe bash is broken in regards to using "any" number after "\" as an octal value. The shell specifications require the leading zero for an octal constant and I don't think this problem would arise if that was fixed. I can forward the info to them anyway. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: [squid-users] Re: my "CPPUNIT" is "broken"... ;-) ?
Henrik Nordstrom wrote: fre 2006-03-17 klockan 19:31 -0800 skrev Linda W: Mystery solved. My shell _expanded_ control sequences by default in echo. (echo "\1" -> becomes "echo ^A"). Apparently there are literals in the configure script like "\\1" "\\2" that were trying to echo a literal '\1' into a "sed" script. Instead it was echoed in as a control-A. Hmm.. so you have replaced /bin/sh with something else than a UNIX shell? Or was it you /bin/echo being different? --- It was the builtin on "bash" compiled to adhere with the System-V standard, and some implementations of ksh and other unix implementations. See "http://ou800doc.caldera.com/en/man/html.1/echo.1.html";. Am I misremembering, aren't their systems were expanded echo is the default? If so then the GNU autoconf people have not run into it yet.. --- Well that could be because the feature was "extended" in BASH. The original standard requires "\0" before an octal number consisting of 1-3 digits. This required \0 to invoke the special decoding. Bash added the "feature" to allow dropping of the leading "0", accepting strings: "\0nnn", "\nnn", and "\xHH". I'm guessing that most bash users run in a shell that has expansion turned off by default or this would have come up before. I am leaning toward thinking this is a case of Bash implementing an incompatible and conflicting extension (by allowing the dropping of the leading 0 of an octal sequence). Good you found what it was, and a way around the problem. Even better if you would enlighten us what it was you were using causing the problem, and how you worked around it. --- For now, I disabled expansion, since it isn't compatible (as you note with existing scripts (like autoconf). Meanwhile, I've submitted a suggestion to go back to requiring the full prefix "\0" before possible interpretation as octal. It seems cleanest if they require "\0" before either an octal or hex encoding, with hex using \0xH[H] and octal using \0N[N[N]]. Linda ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: echo "enhancement" leads to confused legacy script tools...
Henrik Nordstrom wrote: Note: As far as I can tell the echo tests in the configure script generated by autoconf-2.59 tests for quite many things but not \digit as far as I can tell. I have not yet looked into the CVS version. Regards Henrik --- Sorry, haven't been involved too much on this discussion, I'm going to have limited time to look at this in the next day or so. I'm willing to try the CVS versions of autoconf later on, but can't promise when I'll get to it. I can confirm, though, that the bug I'm running into only happened when I rebuilt bash and specified the --enable_xpg_default option. Personally, I don't believe allowing "\o[o[o]]" as an allowed octal sequence is wise when xpg_default is enabled. When "-e" is required, it's not so problematic -- a use can't "accidentally" get an octal sequence unless they have used "-e" -- and then they are (or should be) aware that the string will be interpreted with "\" having special meaning. However, when extended interpretation is the default, the requirement of having a "0" after a "\" reduces the number of "special" strings making it less likely that some application will accidentally enter "octal interpretation mode". It may seem a trivial difference, but the change means that the number of "reserved" 2-byte sequences has doubled: from: 9 2-byte sequences (\a \b \c \f \n \r \t \v \\) and 8 3-byte sequences (\00 \01 .. \07) to: 17 2-byte sequences (original + \0 \1 .. \7) or 18 if you count the addition of "x" for hex Design thoughts: If I wanted to provide maximum compatibility with existing applications, it would be optimal to minimize the number of "reserved" 2-byte sequences by requiring the leading "0 before an octal lead-in. Even better, IMO, would be keeping with existing numeric constant interpretation from most unix source code examples and require \0 as the prefix for octal and \0xHH for hex. That way "\xabsent" (for example) wouldn't cause a surprise conversion to hex, while \0xabsent would seem to stand out more as an indicator of a special embedded numeric (hex) constant. It might be "late" to change the requirement to "\0" is required as the leading for all numeric constants, but as has been stated here, no application should be relying on "\1" being interpreted as "^A" if it is desired that it be portable. While it may seem somewhat "asymmetric", I'd be comfortable requiring the "0" only in the case where the default was extended interpretation (i.e. where "-e" isn't required). As mentioned before, if a user explicitly uses "-e", they they already need to be aware of special "\" processing, so there would be less likelihood of "user surprise". Linda ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: echo "enhancement" leads to confused legacy script tools...
Chet Ramey wrote: The remaining consideration is whether or not there's a significant body of scripts out there that rely on the current behavior. If there isn't, I would strongly consider the change to require a leading `0' in octal constants. I don't think that \x introducing hex constants is as big a problem (it may not be a problem at all). --- Whatever the reasoning, this is essentially what I was suggesting -- requiring a leading zero on octal constants. I thought it would be "cleaner" to have the added compatibility requiring "/0" before any numeric conversions (octal or hex), having the benefit of adding "no new, reserved 2-byte codes". Note: by my "anal retentive" interpretation, if one requires "/0" as a lead-in, then I would use interpretation _only_ for valid octal or hex digits. I.e. /08 and /09 shouldn't be converted, but left "alone", similarly in a hex constant, I wouldn't perform conversion on invalid hex strings, i.e. "/0xg" (or "/xg") . I also would regard the presence of a non-valid character as constant terminator, I.e: "/018" -> "8", just as I'd "presume" is already done for hex constants: /xag (or /0xag) -> "g". As far as xpg_echo being a non-default option, that's "unfortunate". I first learned shell in the late 80's on a korn shell that expanded such control characters by default. I missed their presence when I switched to a BSD-compat shell that didn't expand them. -linda ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
