Re: Process substitution can leak CTLESC (0x01) in output
On 2/16/17 3:36 PM, David Simmons wrote: > [ Re-sending... it doesn't look like this went through the first time. ] > > Bash uses 0x01 (CTLESC) and 0x7F (CTLNUL) bytes within command word strings > that are passed around internally. If either of these bytes appear in the > parser input, they are escaped with an extra 0x01 (CTLESC), but such > escaping is reverted before final use. > > When I use ANSI-C quoting to represent these bytes in a process > substitution context, they appear to be CTLESC-encoded twice in their > journey through bash. For example, 7F becomes 01 7F which becomes 01 01 01 > 7F, then decoded once as 01 7F before final use. This leads to spurious > 0x01 bytes. Thanks for the report. This exists as far back as bash-2.05b, and probably dates from the initial process substitution implementation in the early 1990s. It will be fixed in the next release of bash. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Hang in bgp_delete
On 02/16/2017 11:25 AM, Chet Ramey wrote: > On 2/11/17 5:04 PM, Graham Northup wrote: > >> Bash Version: 4.4 >> Patch Level: 11 >> Release Status: release >> >> Description: >> >> I'm getting a mysterious hang on one of our Arch Linux machines for a >> particular, rather simple script; getting a debugger attached to the >> process after building some debugging symbols, I tracked the hang down >> to this loop in bgp_delete (with some minor formatting): > > It seems obvious in retrospect that the cause is in bgp_add, where there's > no check for the hashed pid colliding with the index into the pidstat list. > Here's a patch that avoids that issue and catches the symptom you found in > case the cause is something else. > > Chet > Just built bash with the patch applied; I'll be checking in every couple of days to see if that happens again. (As I mentioned previously, it's a bit hard to instigate; consider no news to be good news :) . Thanks for the fix! - Graham signature.asc Description: OpenPGP digital signature
