From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52761 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PUM0x-0001mf-VV for qemu-devel@nongnu.org; Sun, 19 Dec 2010 11:21:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PUM0w-0002ni-S1 for qemu-devel@nongnu.org; Sun, 19 Dec 2010 11:21:39 -0500 Received: from mail-pv0-f173.google.com ([74.125.83.173]:47083) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PUM0w-0002nb-Kd for qemu-devel@nongnu.org; Sun, 19 Dec 2010 11:21:38 -0500 Received: by pvh11 with SMTP id 11so635373pvh.4 for ; Sun, 19 Dec 2010 08:21:37 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4D0E27F7.6020006@mail.berlios.de> References: <1292536325-12881-1-git-send-email-weil@mail.berlios.de> <1292690066-4937-1-git-send-email-weil@mail.berlios.de> <7B018D8A-F435-4C36-A87A-20DA984AA8D1@web.de> <4D0E27F7.6020006@mail.berlios.de> From: Blue Swirl Date: Sun, 19 Dec 2010 16:21:17 +0000 Message-ID: Subject: Re: [Qemu-devel] [PATCH v2] win32: Fix CRLF problem in make_device_config.sh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: Paolo Bonzini , =?UTF-8?Q?Andreas_F=C3=A4rber?= , QEMU Developers On Sun, Dec 19, 2010 at 3:42 PM, Stefan Weil wrote: > Am 18.12.2010 19:59, schrieb Blue Swirl: >> >> Thanks, applied. >> >> On Sat, Dec 18, 2010 at 5:09 PM, Andreas F=C3=A4rber >> wrote: >>> >>> Am 18.12.2010 um 17:34 schrieb Stefan Weil: >>> >>>> QEMU source code with CRLF line endings >>>> which is quite common on windows hosts >>>> fails with current make_device_config.sh. >>>> >>>> The awk script gets the name of the included >>>> file with \r, so instead of pci.mak it will >>>> search for pci.mak\r which of course does >>>> not work. >>>> >>>> Fix this by removing any \r. >>>> >>>> v2: >>>> =C2=A0Avoid using sub() and \r with awk because they are unsupported >>>> =C2=A0on some platforms. Use tr to remove \r. This new solution >>>> =C2=A0improves portability and was suggested by Paolo Bonzini. >>>> >>>> Signed-off-by: Stefan Weil >>> >>> Acked-by: Andreas F=C3=A4rber >>>> >>>> --- >>>> make_device_config.sh | =C2=A0 =C2=A02 +- >>>> 1 files changed, 1 insertions(+), 1 deletions(-) >>>> >>>> diff --git a/make_device_config.sh b/make_device_config.sh >>>> index 8abadfe..596fc5b 100644 >>>> --- a/make_device_config.sh >>>> +++ b/make_device_config.sh >>>> @@ -18,7 +18,7 @@ process_includes () { >>>> >>>> f=3D$src >>>> while [ -n "$f" ] ; do >>>> - =C2=A0f=3D`awk '/^include / {ORS=3D" " ; print "'$src_dir'/" $2}' $f= ` >>>> + =C2=A0f=3D`tr -d '\r' < $f | awk '/^include / {ORS=3D" "; print "'$s= rc_dir'/" >>>> $2}'` >>>> =C2=A0[ $? =3D 0 ] || exit 1 >>>> =C2=A0all_includes=3D"$all_includes $f" >>>> done >>>> -- >>>> 1.7.2.3 > > The new code raises a new problem (sorry that I did not detect it earlier= ): > > On hosts with /bin/sh !=3D bash, make displays an error from > make_device_config.sh: > > $ touch default-configs/i386-softmmu.mak > $ make > =C2=A0GEN =C2=A0 i386-softmmu/config-devices.mak > /qemu/make_device_config.sh: 24: cannot open /qemu/default-configs/pci.ma= k : > No such file > > make continues, so the error message is not fatal but a cosmetical issue. > It took me some time to find the reason for this error message although > it is quite simple: > > The filename f which is calculated using awk ends with a blank character > caused by ORS=3D" ". > > Obviously this blank does not matter for bash and other shells when > $f is used as a parameter. I/O redirection with bash works, too. > But dash (and perhaps other simple shells) work different. For dash, > < $f works like < "$f", so the blank is part of the filename, > and "pci.mak " of course does not exist. Is this a dash bug or a feature? > > Using ORS=3D"" solves the problem for me, but might raise new compatibili= ty > problems (is an empty records separator always supported?). > > Andreas, may I ask you for one more test? > > $ echo -e 'include xy\r' | tr -d '\r' | awk '/^include / {ORS=3D""; print= $2}' > | od -c > > It should return 0000002, not 0000003 like the previous test: > > 0000000 =C2=A0 x =C2=A0 y > 0000002 How about something like this instead: (SRC_DIR=3D/src; echo -e 'include xy' | sed -n 's|^include *\(.*\)|'$SRC_DIR/'\1|p') /src/xy