From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74129 invoked by alias); 4 Sep 2016 09:11:05 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 74108 invoked by uid 89); 4 Sep 2016 09:11:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_20,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=investigated, eblakeredhatcom, eblake@redhat.com, pipes X-HELO: mail-it0-f53.google.com Received: from mail-it0-f53.google.com (HELO mail-it0-f53.google.com) (209.85.214.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 04 Sep 2016 09:11:01 +0000 Received: by mail-it0-f53.google.com with SMTP id e124so105436669ith.0 for ; Sun, 04 Sep 2016 02:11:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3VS9m+ncrSQzAnQvMBvzAcc8Sk9D5SNpsISk35MmBgs=; b=lStf7D/JImzYDUvukRw13HciY3uLiQtrbhxtXLVqzwBCyIaVCHT2xO2Jkqftb5wr8m E8QPHjr/VmB25hYNS5JOMnom/i7uol+b0kjtWmPvHVT4fvhYjC/qMuXexbks7XG3zPEb jFD7HplLjeseJYKCOCtGmy966pSm5k7K7TWP23lNEHC1EnOdRlna8/odr+3rXRiECckL UcinB0qhIn/qI0tiygpPMrWUoQBJNeF5grVBoGFPw/isqN7mkZQv0hNP0t7lfmC4CJiN 1zVTmm73JZUKcSHzfpkvRisX5dSMHahGHz9m9ae3fjBkQXLOIHAZmKjHdx4N8uKGHutk I2SA== X-Gm-Message-State: AE9vXwO2cpDiFLhRZWNSE4l7HXehFMc5YhJtCIDf6ofw31N6PMd05FZ5Shz02WqUkaWl4NPk0TLhWbhqLoapkg== X-Received: by 10.36.225.72 with SMTP id n69mr14142741ith.16.1472980259672; Sun, 04 Sep 2016 02:10:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.116.26 with HTTP; Sun, 4 Sep 2016 02:10:59 -0700 (PDT) In-Reply-To: References: <8980687a-967e-88d8-2a94-f485731fafe9@redhat.com> <9940d9b9cd565fbb0d5b395565197dfd@xs4all.nl> <0294c48e-8e96-f554-3e05-6b7771dfb96e@redhat.com> From: Gene Pavlovsky Date: Sun, 04 Sep 2016 09:11:00 -0000 Message-ID: Subject: Re: bash: igncr shell option breaks my PS1 prompt To: cygwin@cygwin.com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-09/txt/msg00056.txt.bz2 On 2 September 2016 at 16:32, Eric Blake wrote: > On 09/02/2016 06:52 AM, Gene Pavlovsky wrote: >> Dear Eric Blake, >> >> Basically, I don't want to set `igncr` as system-wide shell option >> (e.g. through SHELLOPTS). > > Don't use it, then. I highly recommend avoiding 'igncr', because it > exists only as a crutch. The real solution is to fix your environment > to be binary-clean, at which point you no longer need igncr. But I also > understand that fixing an environment to be binary-clean can be > expensive, so 'igncr' remains as the crutch. Exactly, so I would really prefer to avoid crutches. >> So, how do I keep an existing bash script, that uses `read` piped from >> the output of a Windows console program that uses CRLF as newlines, >> working, without modifying the script? I don't see how it's possible >> with the current situation. > By piping the output of the Windows program through d2u before handing > it to 'read'. The script in question (at the moment) is [AutoMySQLBackup](https://sourceforge.net/projects/automysqlbackup/). I didn't make it, I might want to update it when a new version comes out. Having to add either "set -o igncr" or "| d2u" to the script creates a maintainability problem - if I ever update it, I should remember that I did that to this script, and do it again after an update. I could make a wrapper for mysql.exe, that pipes it's output through d2u - which sounds like a bad crutch as well. Worst thing is, I should spend time investigating why some (other) script is failing in a non-obvious fashion. Looking through the code to find out which Windows program it uses that should be piped through d2u. No matter how you look it at, the recent change to `read` might have broken many scripts that were functioning before. The solution you suggested means broken scripts should first be found, then investigated, then some Cygwin-specific code added to them. That sounds like a lot of work, and if the scripts in question are third-party, a maintainability problem. At the moment, I'm forced to use an older version of bash due to this particular issue. Do you see a better solution here? Regards, --Gene -- 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