X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=J060PHU+qd4txK4u B/BVrqAadTYwPVA7gpxdjXISSt3qFETV4K2z0klAnnmTjF2USnuiuReMxj+WErTj fyq30mBGymdkxsgmD54IrHqprC7LR00rjXNALjowgh0+4d8VaHZ6BwpIsn4kFYw4 BdlBt74RpgaH+5lrRbr7FulmOkk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=yaBnPwpAfFnxBDx7eWuVWE ZeOlo=; b=b3WEmqGJxGRDY0L1h3M6e+Ejrh2LR3njeqzGURpHaYNcai2Gue31PM sERuw2HUr5R4M1eIRQaqq+CNPykveYDtffab5ls3rDt0q+1u6BYWqrCPQLswunAq EaQnnUlHRaBKnyetbb2JwzpldtN/rfChN+R1QRfNVxt5ffafyv/34= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=loose, H*f:sk:1de2efd, H*MI:sk:1de2efd, H*i:sk:1de2efd X-HELO: mail-it0-f44.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0wTELJJonSof9mIK4F183u/Wpc5fkxbvJ1PmaO0ESEo=; b=jTxSWDmKMvYPm4ux1qiBaQEVuTXze3HK6PZUp48+QSWT+wi8KFfUbwpY6m1gSzBbo3 fzZkDMAZoYoXXKVo5UwWMlJ5anIXBcyyRP8Qw8xFQpE7xAI281/oNQQgmKPJZGmOGBuw jwFCP1hqOGAYLE5ExqeTsQBvGLhYwDaKwTRLdte3e2kScYCkp/MtAw/LcCYDehwY6qtK D9lr9DtDEh49ymLQKl/1BynJFbmMC5WCjpfcdRJxu+fzK0gHXh1b8Mj4b5ZTjbFWMO3V oVqOyyJDUGBMRhQ+mCq5Zp6aQZHN4wXuNBAMAQFF5CERfyNacFZD4gljInT57HUBGNqJ J4EQ== X-Gm-Message-State: AE9vXwMgQCcAu2vq7DhvxgcCam4t9dnregUq9B9T6wge0HilQN29GK2shUECJZyB5sDJpQ== X-Received: by 10.107.6.32 with SMTP id 32mr1346247iog.174.1472590611768; Tue, 30 Aug 2016 13:56:51 -0700 (PDT) Subject: Re: Script broken after updating bash to 4.3.46-7? To: cygwin AT cygwin DOT com References: <93be816b-952c-20cd-575e-940cdf4fbbd1 AT redhat DOT com> <1de2efdc-b26c-4914-580c-1a640d0a46fd AT redhat DOT com> From: cyg Simple Message-ID: <7314ffba-a927-f565-e38e-7454d6c2ef0f@gmail.com> Date: Tue, 30 Aug 2016 16:57:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1de2efdc-b26c-4914-580c-1a640d0a46fd@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes On 8/30/2016 1:38 PM, Eric Blake wrote: > On 08/30/2016 12:04 PM, cyg Simple wrote: >> On 8/29/2016 2:30 PM, Eric Blake wrote: >>> >>> Simplest fix: >>> >>> read ... < <(mysql ... | dos2unix) >>> >> >> This will break when the data returned by mysql is supposed to contain \r. >> >>> There. Now you aren't feeding \r to read in the first place. >>> >> >> But you might want to feed \r to read. It isn't a fix, it is a >> potential work around dependent on the data set results. If a read that >> is supposed to be reading binary data doesn't pass all of the data to >> the routine then it is broken. > > Now we're talking past each other. > > That's what the recent bash fixed. 'read' in bash 3.2.42-4 was broken - > it corrupted binary data, with no recourse, by eating \r (and worse, by > sometimes eating the byte after \r). 'read' in bash 3.2.46-7 is fixed - > by default it is strictly binary (all bytes are read as-is, including > \r), but can also be switched to text mode (using 'igncr', all \r are > ignored). If you want to preserve mid-line \r but treat line endings of > \r\n as a single byte, then leave binary mode on and strip the line > endings via a separate tool like d2u (note, however, that it is very > rare to have data where mid-line \r is important but line-ending \r\n > should be treated as plain \n). > > I strongly think that using igncr is a crutch, and you normally > shouldn't use it; particularly not if you want to be portable to other > platforms. Instead, massaging your data through d2u is a great way to > be portable. But sometimes the ease of ignoring ALL \r is easier than > worrying about portability, so I keep the 'igncr' code in Cygwin. > > And it is only because the OP tried using 'igncr' in the first place > (whether or not it was actually needed) that we have now flushed out the > existence of a latent bug in the 'igncr' implementation that interacts > weirdly with $()\n in PS1. On that front, I'm still hoping to find time > to debug and/or for someone to post a patch. But whether PS1 behaves > weirdly under 'igncr' is orthogonal to my suggestion above - using > 'mysql|d2u' is a great way to avoid the need to worry about 'igncr'. > Thank you for the retort Eric. Happy to know that it is fixed which in the back of my mind I knew already. I can imagine data such as full message email or a small document data containing \r\n as valid data in the database field and if you use a line ending conversion utility you might loose that data. -- cyg Simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple