[Qemu-devel] [PATCH] win32: Fix CRLF problem in make_device_config.sh

[Qemu-devel] [PATCH] win32: Fix CRLF problem in make_device_config.sh

[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 at end of line.

Signed-off-by: Stefan Weil <weil@mail.berlios.de>
---
 make_device_config.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/make_device_config.sh b/make_device_config.sh
index 8abadfe..f0ce10a 100644
--- a/make_device_config.sh
+++ b/make_device_config.sh
@@ -18,7 +18,7 @@ process_includes () {
 
 f=$src
 while [ -n "$f" ] ; do
-  f=`awk '/^include / {ORS=" " ; print "'$src_dir'/" $2}' $f`
+  f=`awk '/^include / {ORS=" "; sub(/\r$/, "", $2); print "'$src_dir'/" $2}' $f`
   [ $? = 0 ] || exit 1
   all_includes="$all_includes $f"
 done
-- 
1.7.2.3

[Qemu-devel] Re: [PATCH] win32: Fix CRLF problem in make_device_config.sh

[Paolo Bonzini]

On 12/16/2010 10:52 PM, Stefan Weil wrote:
> 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 at end of line.

Why isn't cygwin (or whatever you're using) removing it?

Paolo

Re: [Qemu-devel] Re: [PATCH] win32: Fix CRLF problem in make_device_config.sh

[Andreas Färber]

Am 16.12.2010 um 23:42 schrieb Paolo Bonzini:

> On 12/16/2010 10:52 PM, Stefan Weil wrote:
>> 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 at end of line.
>
> Why isn't cygwin (or whatever you're using) removing it?

I believe Cygwin had an option to choose the line ending style once  
during setup. By default it uses Unix-style line endings.
If someone edits source files in some Windows editor, the above issue  
seems likely.

My awk foo is insufficient to ack the patch but if it doesn't break  
Unices it looks reasonable to me.

Andreas

Re: [Qemu-devel] Re: [PATCH] win32: Fix CRLF problem in make_device_config.sh

[Paolo Bonzini]

On 12/17/2010 02:34 PM, Andreas Färber wrote:
>>>
>>> Fix this by removing any \r at end of line.
>>
>> Why isn't cygwin (or whatever you're using) removing it?
>
> I believe Cygwin had an option to choose the line ending style once
> during setup. By default it uses Unix-style line endings.
> If someone edits source files in some Windows editor, the above issue
> seems likely.

Hmm, MSYS is more problematic: the manual says "In the MSYS environment 
under Windows, `gawk' automatically uses binary mode for reading and 
writing files. Thus there is no need to use the `BINMODE' variable. 
This can cause problems with other Unix-like components that have been 
ported to Windows that expect `gawk' to do automatic translationof 
`"\r\n"', since it won't.".

> My awk foo is insufficient to ack the patch but if it doesn't break
> Unices it looks reasonable to me.

I'd be worried a bit about Solaris and other proprietary OSes with 
prehistoric Unix utilities.  Perhaps using \012 instead of \r is better.

Paolo

Re: [Qemu-devel] Re: [PATCH] win32: Fix CRLF problem in make_device_config.sh

[Stefan Weil]

Am 17.12.2010 14:44, schrieb Paolo Bonzini:
> On 12/17/2010 02:34 PM, Andreas Färber wrote:
>>>>
>>>> Fix this by removing any \r at end of line.
>>>
>>> Why isn't cygwin (or whatever you're using) removing it?
>>
>> I believe Cygwin had an option to choose the line ending style once
>> during setup. By default it uses Unix-style line endings.
>> If someone edits source files in some Windows editor, the above issue
>> seems likely.
>
> Hmm, MSYS is more problematic: the manual says "In the MSYS 
> environment under Windows, `gawk' automatically uses binary mode for 
> reading and writing files. Thus there is no need to use the `BINMODE' 
> variable. This can cause problems with other Unix-like components that 
> have been ported to Windows that expect `gawk' to do automatic 
> translationof `"\r\n"', since it won't.".

I had the \r problem when using msys. There seem to be several factors:

* git configuration (add CR / don't add CR)
* msys mount options (binmode / textmode)
* (g)awk (read binary)

>
>> My awk foo is insufficient to ack the patch but if it doesn't break
>> Unices it looks reasonable to me.
>
> I'd be worried a bit about Solaris and other proprietary OSes with 
> prehistoric Unix utilities.  Perhaps using \012 instead of \r is better.
>
> Paolo

I currently have no possibility to run tests with other awk implementations,
so I cannot tell whether \012 is needed at all (\r is not a new invention).
Do all awk versions support regular expressions with characters in
octal encoding?.

Perhaps we can wait several days for feedback from users with an old awk
and apply the patch if there is none.

Regards,
Stefan

Re: [Qemu-devel] Re: [PATCH] win32: Fix CRLF problem in make_device_config.sh

[Andreas Färber]

Am 17.12.2010 um 20:01 schrieb Stefan Weil:

> Am 17.12.2010 14:44, schrieb Paolo Bonzini:
>> On 12/17/2010 02:34 PM, Andreas Färber wrote:
>>>>>
>>>>> Fix this by removing any \r at end of line.
>>>>
>>>> Why isn't cygwin (or whatever you're using) removing it?
>>>
>>> I believe Cygwin had an option to choose the line ending style once
>>> during setup. By default it uses Unix-style line endings.
>>> If someone edits source files in some Windows editor, the above  
>>> issue
>>> seems likely.
>>
>> Hmm, MSYS is more problematic: the manual says "In the MSYS  
>> environment under Windows, `gawk' automatically uses binary mode  
>> for reading and writing files. Thus there is no need to use the  
>> `BINMODE' variable. This can cause problems with other Unix-like  
>> components that have been ported to Windows that expect `gawk' to  
>> do automatic translationof `"\r\n"', since it won't.".
>
> I had the \r problem when using msys. There seem to be several  
> factors:
>
> * git configuration (add CR / don't add CR)
> * msys mount options (binmode / textmode)
> * (g)awk (read binary)
>
>>
>>> My awk foo is insufficient to ack the patch but if it doesn't break
>>> Unices it looks reasonable to me.
>>
>> I'd be worried a bit about Solaris and other proprietary OSes with  
>> prehistoric Unix utilities.  Perhaps using \012 instead of \r is  
>> better.
>>
>> Paolo
>
> I currently have no possibility to run tests with other awk  
> implementations,
> so I cannot tell whether \012 is needed at all (\r is not a new  
> invention).
> Do all awk versions support regular expressions with characters in
> octal encoding?.
>
> Perhaps we can wait several days for feedback from users with an old  
> awk
> and apply the patch if there is none.

I have an open bug ticket wrt configure being broken on Solaris 10 due  
to tracing shell incompatibilities.

If you provide a small self-contained example I can check though.

Andreas

Re: [Qemu-devel] Re: [PATCH] win32: Fix CRLF problem in make_device_config.sh

[Stefan Weil]

Am 17.12.2010 20:33, schrieb Andreas Färber:
> Am 17.12.2010 um 20:01 schrieb Stefan Weil:
>
>> Am 17.12.2010 14:44, schrieb Paolo Bonzini:
>>> On 12/17/2010 02:34 PM, Andreas Färber wrote:
>>>>>>
>>>>>> Fix this by removing any \r at end of line.
>>>>>
>>>>> Why isn't cygwin (or whatever you're using) removing it?
>>>>
>>>> I believe Cygwin had an option to choose the line ending style once
>>>> during setup. By default it uses Unix-style line endings.
>>>> If someone edits source files in some Windows editor, the above issue
>>>> seems likely.
>>>
>>> Hmm, MSYS is more problematic: the manual says "In the MSYS 
>>> environment under Windows, `gawk' automatically uses binary mode for 
>>> reading and writing files. Thus there is no need to use the 
>>> `BINMODE' variable. This can cause problems with other Unix-like 
>>> components that have been ported to Windows that expect `gawk' to do 
>>> automatic translationof `"\r\n"', since it won't.".
>>
>> I had the \r problem when using msys. There seem to be several factors:
>>
>> * git configuration (add CR / don't add CR)
>> * msys mount options (binmode / textmode)
>> * (g)awk (read binary)
>>
>>>
>>>> My awk foo is insufficient to ack the patch but if it doesn't break
>>>> Unices it looks reasonable to me.
>>>
>>> I'd be worried a bit about Solaris and other proprietary OSes with 
>>> prehistoric Unix utilities.  Perhaps using \012 instead of \r is 
>>> better.
>>>
>>> Paolo
>>
>> I currently have no possibility to run tests with other awk 
>> implementations,
>> so I cannot tell whether \012 is needed at all (\r is not a new 
>> invention).
>> Do all awk versions support regular expressions with characters in
>> octal encoding?.
>>
>> Perhaps we can wait several days for feedback from users with an old awk
>> and apply the patch if there is none.
>
> I have an open bug ticket wrt configure being broken on Solaris 10 due 
> to tracing shell incompatibilities.
>
> If you provide a small self-contained example I can check though.
>
> Andreas


Example (needs bash's echo -e):

# create line with crlf ending:
echo -e 'include xy\r' >file

# returns xy\r:
awk '/^include / {ORS=" "; print $2}' file | od

# should return xy:
awk '/^include / {ORS=" "; sub(/\r$/, "", $2); print $2}' file | od

Regards,
Stefan

[Qemu-devel] Re: [PATCH] win32: Fix CRLF problem in make_device_config.sh

[Paolo Bonzini]

On 12/17/2010 08:01 PM, Stefan Weil wrote:
> I currently have no possibility to run tests with other awk
> implementations,
> so I cannot tell whether \012 is needed at all (\r is not a new invention).
> Do all awk versions support regular expressions with characters in
> octal encoding?.

The awk manual reports \b, \f and \r as unportable, and says that \a, 
\v, \x have been introduced after those.  \x is not in POSIX.

That leaves \a, \n, \t, \v and \NNN as portable.

Paolo

Re: [Qemu-devel] Re: [PATCH] win32: Fix CRLF problem in make_device_config.sh

[Andreas Färber]

Am 17.12.2010 um 20:54 schrieb Stefan Weil:

> Am 17.12.2010 20:33, schrieb Andreas Färber:
>> Am 17.12.2010 um 20:01 schrieb Stefan Weil:
>>
>>> Am 17.12.2010 14:44, schrieb Paolo Bonzini:
>>>> On 12/17/2010 02:34 PM, Andreas Färber wrote:
>>>>>>>
>>>>>>> Fix this by removing any \r at end of line.
>>>>>>
>>>>>> Why isn't cygwin (or whatever you're using) removing it?
>>>>>
>>>>> I believe Cygwin had an option to choose the line ending style  
>>>>> once
>>>>> during setup. By default it uses Unix-style line endings.
>>>>> If someone edits source files in some Windows editor, the above  
>>>>> issue
>>>>> seems likely.
>>>>
>>>> Hmm, MSYS is more problematic: the manual says "In the MSYS  
>>>> environment under Windows, `gawk' automatically uses binary mode  
>>>> for reading and writing files. Thus there is no need to use the  
>>>> `BINMODE' variable. This can cause problems with other Unix-like  
>>>> components that have been ported to Windows that expect `gawk' to  
>>>> do automatic translationof `"\r\n"', since it won't.".
>>>
>>> I had the \r problem when using msys. There seem to be several  
>>> factors:
>>>
>>> * git configuration (add CR / don't add CR)
>>> * msys mount options (binmode / textmode)
>>> * (g)awk (read binary)
>>>
>>>>
>>>>> My awk foo is insufficient to ack the patch but if it doesn't  
>>>>> break
>>>>> Unices it looks reasonable to me.
>>>>
>>>> I'd be worried a bit about Solaris and other proprietary OSes  
>>>> with prehistoric Unix utilities.  Perhaps using \012 instead of  
>>>> \r is better.
>>>>
>>>> Paolo
>>>
>>> I currently have no possibility to run tests with other awk  
>>> implementations,
>>> so I cannot tell whether \012 is needed at all (\r is not a new  
>>> invention).
>>> Do all awk versions support regular expressions with characters in
>>> octal encoding?.
>>>
>>> Perhaps we can wait several days for feedback from users with an  
>>> old awk
>>> and apply the patch if there is none.
>>
>> I have an open bug ticket wrt configure being broken on Solaris 10  
>> due to tracing shell incompatibilities.
>>
>> If you provide a small self-contained example I can check though.
>>
>> Andreas
>
>
> Example (needs bash's echo -e):
>
> # create line with crlf ending:
> echo -e 'include xy\r' >file
>
> # returns xy\r:
> awk '/^include / {ORS=" "; print $2}' file | od

0000000 074570 020015
0000004

> # should return xy:
> awk '/^include / {ORS=" "; sub(/\r$/, "", $2); print $2}' file | od

awk: syntax error near line 1
awk: illegal statement near line 1
0000000

Andreas

[Qemu-devel] Re: [PATCH] win32: Fix CRLF problem in make_device_config.sh

[Paolo Bonzini]

On 12/17/2010 10:00 PM, Andreas Färber wrote:
> Am 17.12.2010 um 20:54 schrieb Stefan Weil:
>
>> Am 17.12.2010 20:33, schrieb Andreas Färber:
>>> Am 17.12.2010 um 20:01 schrieb Stefan Weil:
>>>
>>>> Am 17.12.2010 14:44, schrieb Paolo Bonzini:
>>>>> On 12/17/2010 02:34 PM, Andreas Färber wrote:
>>>>>>>>
>>>>>>>> Fix this by removing any \r at end of line.
>>>>>>>
>>>>>>> Why isn't cygwin (or whatever you're using) removing it?
>>>>>>
>>>>>> I believe Cygwin had an option to choose the line ending style once
>>>>>> during setup. By default it uses Unix-style line endings.
>>>>>> If someone edits source files in some Windows editor, the above issue
>>>>>> seems likely.
>>>>>
>>>>> Hmm, MSYS is more problematic: the manual says "In the MSYS
>>>>> environment under Windows, `gawk' automatically uses binary mode
>>>>> for reading and writing files. Thus there is no need to use the
>>>>> `BINMODE' variable. This can cause problems with other Unix-like
>>>>> components that have been ported to Windows that expect `gawk' to
>>>>> do automatic translationof `"\r\n"', since it won't.".
>>>>
>>>> I had the \r problem when using msys. There seem to be several factors:
>>>>
>>>> * git configuration (add CR / don't add CR)
>>>> * msys mount options (binmode / textmode)
>>>> * (g)awk (read binary)
>>>>
>>>>>
>>>>>> My awk foo is insufficient to ack the patch but if it doesn't break
>>>>>> Unices it looks reasonable to me.
>>>>>
>>>>> I'd be worried a bit about Solaris and other proprietary OSes with
>>>>> prehistoric Unix utilities. Perhaps using \012 instead of \r is
>>>>> better.
>>>>>
>>>>> Paolo
>>>>
>>>> I currently have no possibility to run tests with other awk
>>>> implementations,
>>>> so I cannot tell whether \012 is needed at all (\r is not a new
>>>> invention).
>>>> Do all awk versions support regular expressions with characters in
>>>> octal encoding?.
>>>>
>>>> Perhaps we can wait several days for feedback from users with an old
>>>> awk
>>>> and apply the patch if there is none.
>>>
>>> I have an open bug ticket wrt configure being broken on Solaris 10
>>> due to tracing shell incompatibilities.
>>>
>>> If you provide a small self-contained example I can check though.
>>>
>>> Andreas
>>
>>
>> Example (needs bash's echo -e):
>>
>> # create line with crlf ending:
>> echo -e 'include xy\r' >file
>>
>> # returns xy\r:
>> awk '/^include / {ORS=" "; print $2}' file | od
>
> 0000000 074570 020015
> 0000004
>
>> # should return xy:
>> awk '/^include / {ORS=" "; sub(/\r$/, "", $2); print $2}' file | od
>
> awk: syntax error near line 1
> awk: illegal statement near line 1
> 0000000

Can you try \015 instead of \r?

Paolo

[Qemu-devel] Re: [PATCH] win32: Fix CRLF problem in make_device_config.sh

[Andreas Färber]

Am 17.12.2010 um 22:25 schrieb Paolo Bonzini:

> On 12/17/2010 10:00 PM, Andreas Färber wrote:
>> Am 17.12.2010 um 20:54 schrieb Stefan Weil:
>>
>>> Am 17.12.2010 20:33, schrieb Andreas Färber:
>>>> Am 17.12.2010 um 20:01 schrieb Stefan Weil:
>>>>
>>>>> Am 17.12.2010 14:44, schrieb Paolo Bonzini:
>>>>>> On 12/17/2010 02:34 PM, Andreas Färber wrote:
>>>>>>>>>
>>>>>>>>> Fix this by removing any \r at end of line.
>>>>>>>>
>>>>>>>> Why isn't cygwin (or whatever you're using) removing it?
>>>>>>>
>>>>>>> I believe Cygwin had an option to choose the line ending style  
>>>>>>> once
>>>>>>> during setup. By default it uses Unix-style line endings.
>>>>>>> If someone edits source files in some Windows editor, the  
>>>>>>> above issue
>>>>>>> seems likely.
>>>>>>
>>>>>> Hmm, MSYS is more problematic: the manual says "In the MSYS
>>>>>> environment under Windows, `gawk' automatically uses binary mode
>>>>>> for reading and writing files. Thus there is no need to use the
>>>>>> `BINMODE' variable. This can cause problems with other Unix-like
>>>>>> components that have been ported to Windows that expect `gawk' to
>>>>>> do automatic translationof `"\r\n"', since it won't.".
>>>>>
>>>>> I had the \r problem when using msys. There seem to be several  
>>>>> factors:
>>>>>
>>>>> * git configuration (add CR / don't add CR)
>>>>> * msys mount options (binmode / textmode)
>>>>> * (g)awk (read binary)
>>>>>
>>>>>>
>>>>>>> My awk foo is insufficient to ack the patch but if it doesn't  
>>>>>>> break
>>>>>>> Unices it looks reasonable to me.
>>>>>>
>>>>>> I'd be worried a bit about Solaris and other proprietary OSes  
>>>>>> with
>>>>>> prehistoric Unix utilities. Perhaps using \012 instead of \r is
>>>>>> better.
>>>>>>
>>>>>> Paolo
>>>>>
>>>>> I currently have no possibility to run tests with other awk
>>>>> implementations,
>>>>> so I cannot tell whether \012 is needed at all (\r is not a new
>>>>> invention).
>>>>> Do all awk versions support regular expressions with characters in
>>>>> octal encoding?.
>>>>>
>>>>> Perhaps we can wait several days for feedback from users with an  
>>>>> old
>>>>> awk
>>>>> and apply the patch if there is none.
>>>>
>>>> I have an open bug ticket wrt configure being broken on Solaris 10
>>>> due to tracing shell incompatibilities.
>>>>
>>>> If you provide a small self-contained example I can check though.
>>>>
>>>> Andreas
>>>
>>>
>>> Example (needs bash's echo -e):
>>>
>>> # create line with crlf ending:
>>> echo -e 'include xy\r' >file
>>>
>>> # returns xy\r:
>>> awk '/^include / {ORS=" "; print $2}' file | od
>>
>> 0000000 074570 020015
>> 0000004
>>
>>> # should return xy:
>>> awk '/^include / {ORS=" "; sub(/\r$/, "", $2); print $2}' file | od
>>
>> awk: syntax error near line 1
>> awk: illegal statement near line 1
>> 0000000
>
> Can you try \015 instead of \r?

Same.

Andreas

[Qemu-devel] Re: [PATCH] win32: Fix CRLF problem in make_device_config.sh

[Paolo Bonzini]

On 12/17/2010 11:17 PM, Andreas Färber wrote:
>>>> Example (needs bash's echo -e):
>>>>
>>>> # create line with crlf ending:
>>>> echo -e 'include xy\r' >file
>>>>
>>>> # returns xy\r:
>>>> awk '/^include / {ORS=" "; print $2}' file | od
>>>
>>> 0000000 074570 020015
>>> 0000004
>>>
>>>> # should return xy:
>>>> awk '/^include / {ORS=" "; sub(/\r$/, "", $2); print $2}' file | od
>>>
>>> awk: syntax error near line 1
>>> awk: illegal statement near line 1
>>> 0000000
>>
>> Can you try \015 instead of \r?
>
> Same.

Then I guess Stefan should use

tr -d '\015' < file | awk '/^include / {ORS=" "; print $2}'

or something like that.

Paolo

[Qemu-devel] Re: [PATCH] win32: Fix CRLF problem in make_device_config.sh

[Stefan Weil]

Am 18.12.2010 00:24, schrieb Paolo Bonzini:
> On 12/17/2010 11:17 PM, Andreas Färber wrote:
>>>>> Example (needs bash's echo -e):
>>>>>
>>>>> # create line with crlf ending:
>>>>> echo -e 'include xy\r' >file
>>>>>
>>>>> # returns xy\r:
>>>>> awk '/^include / {ORS=" "; print $2}' file | od
>>>>
>>>> 0000000 074570 020015
>>>> 0000004
>>>>
>>>>> # should return xy:
>>>>> awk '/^include / {ORS=" "; sub(/\r$/, "", $2); print $2}' file | od
>>>>
>>>> awk: syntax error near line 1
>>>> awk: illegal statement near line 1
>>>> 0000000
>>>
>>> Can you try \015 instead of \r?
>>
>> Same.
>
> Then I guess Stefan should use
>
> tr -d '\015' < file | awk '/^include / {ORS=" "; print $2}'
>
> or something like that.
>
> Paolo


Andreas, please try this variant of Paolo's suggestion:

tr -d '\r' file | awk '/^include / {ORS=" "; print $2}' | od -c

I found some SunOS man pages online: tr should work with
'\r', and awk does not support the sub function (therefore
you always got a syntax error).

If the new code works, I'll send a modified patch.

Thanks,
Stefan

Re: [Qemu-devel] Re: [PATCH] win32: Fix CRLF problem in make_device_config.sh

[Andreas Färber]

Am 18.12.2010 um 11:19 schrieb Stefan Weil:

> Am 18.12.2010 00:24, schrieb Paolo Bonzini:
>> On 12/17/2010 11:17 PM, Andreas Färber wrote:
>>>>>> Example (needs bash's echo -e):
>>>>>>
>>>>>> # create line with crlf ending:
>>>>>> echo -e 'include xy\r' >file
>>>>>>
>>>>>> # returns xy\r:
>>>>>> awk '/^include / {ORS=" "; print $2}' file | od
>>>>>
>>>>> 0000000 074570 020015
>>>>> 0000004
>>>>>
>>>>>> # should return xy:
>>>>>> awk '/^include / {ORS=" "; sub(/\r$/, "", $2); print $2}' file  
>>>>>> | od
>>>>>
>>>>> awk: syntax error near line 1
>>>>> awk: illegal statement near line 1
>>>>> 0000000
>>>>
>>>> Can you try \015 instead of \r?
>>>
>>> Same.
>>
>> Then I guess Stefan should use
>>
>> tr -d '\015' < file | awk '/^include / {ORS=" "; print $2}'
>>
>> or something like that.
>>
>> Paolo
>
>
> Andreas, please try this variant of Paolo's suggestion:
>
> tr -d '\r' file | awk '/^include / {ORS=" "; print $2}' | od -c

Like that, the tr hangs. The following works better:

bash-3.00$ tr -d '\r' < file | awk '/^include / {ORS=" "; print $2}' |  
od -c
0000000   x   y
0000003

Andreas

Re: [Qemu-devel] Re: [PATCH] win32: Fix CRLF problem in make_device_config.sh

[Stefan Weil]

Am 18.12.2010 13:02, schrieb Andreas Färber:
> Am 18.12.2010 um 11:19 schrieb Stefan Weil:
>
>> Am 18.12.2010 00:24, schrieb Paolo Bonzini:
>>> On 12/17/2010 11:17 PM, Andreas Färber wrote:
>>>>>>> Example (needs bash's echo -e):
>>>>>>>
>>>>>>> # create line with crlf ending:
>>>>>>> echo -e 'include xy\r' >file
>>>>>>>
>>>>>>> # returns xy\r:
>>>>>>> awk '/^include / {ORS=" "; print $2}' file | od
>>>>>>
>>>>>> 0000000 074570 020015
>>>>>> 0000004
>>>>>>
>>>>>>> # should return xy:
>>>>>>> awk '/^include / {ORS=" "; sub(/\r$/, "", $2); print $2}' file | od
>>>>>>
>>>>>> awk: syntax error near line 1
>>>>>> awk: illegal statement near line 1
>>>>>> 0000000
>>>>>
>>>>> Can you try \015 instead of \r?
>>>>
>>>> Same.
>>>
>>> Then I guess Stefan should use
>>>
>>> tr -d '\015' < file | awk '/^include / {ORS=" "; print $2}'
>>>
>>> or something like that.
>>>
>>> Paolo
>>
>>
>> Andreas, please try this variant of Paolo's suggestion:
>>
>> tr -d '\r' file | awk '/^include / {ORS=" "; print $2}' | od -c
>
> Like that, the tr hangs. The following works better:
>
> bash-3.00$ tr -d '\r' < file | awk '/^include / {ORS=" "; print $2}' | 
> od -c
> 0000000   x   y
> 0000003
>
> Andreas

Mea culpa. Of course tr expects its data from stdin - the '<' got lost
when I wrote the mail.

Thanks for the testing.

Stefan

[Qemu-devel] [PATCH v2] win32: Fix CRLF problem in make_device_config.sh

[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:
    Avoid using sub() and \r with awk because they are unsupported
    on some platforms. Use tr to remove \r. This new solution
    improves portability and was suggested by Paolo Bonzini.

Signed-off-by: Stefan Weil <weil@mail.berlios.de>
---
 make_device_config.sh |    2 +-
 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=$src
 while [ -n "$f" ] ; do
-  f=`awk '/^include / {ORS=" " ; print "'$src_dir'/" $2}' $f`
+  f=`tr -d '\r' < $f | awk '/^include / {ORS=" "; print "'$src_dir'/" $2}'`
   [ $? = 0 ] || exit 1
   all_includes="$all_includes $f"
 done
-- 
1.7.2.3

Re: [Qemu-devel] [PATCH v2] win32: Fix CRLF problem in make_device_config.sh

[Andreas Färber]

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:
>    Avoid using sub() and \r with awk because they are unsupported
>    on some platforms. Use tr to remove \r. This new solution
>    improves portability and was suggested by Paolo Bonzini.
>
> Signed-off-by: Stefan Weil <weil@mail.berlios.de>

Acked-by: Andreas Färber <andreas.faerber@web.de>

> ---
> make_device_config.sh |    2 +-
> 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=$src
> while [ -n "$f" ] ; do
> -  f=`awk '/^include / {ORS=" " ; print "'$src_dir'/" $2}' $f`
> +  f=`tr -d '\r' < $f | awk '/^include / {ORS=" "; print  
> "'$src_dir'/" $2}'`
>   [ $? = 0 ] || exit 1
>   all_includes="$all_includes $f"
> done
> -- 
> 1.7.2.3

Re: [Qemu-devel] [PATCH v2] win32: Fix CRLF problem in make_device_config.sh

[Blue Swirl]

Thanks, applied.

On Sat, Dec 18, 2010 at 5:09 PM, Andreas Färber <andreas.faerber@web.de> 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:
>>   Avoid using sub() and \r with awk because they are unsupported
>>   on some platforms. Use tr to remove \r. This new solution
>>   improves portability and was suggested by Paolo Bonzini.
>>
>> Signed-off-by: Stefan Weil <weil@mail.berlios.de>
>
> Acked-by: Andreas Färber <andreas.faerber@web.de>
>
>> ---
>> make_device_config.sh |    2 +-
>> 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=$src
>> while [ -n "$f" ] ; do
>> -  f=`awk '/^include / {ORS=" " ; print "'$src_dir'/" $2}' $f`
>> +  f=`tr -d '\r' < $f | awk '/^include / {ORS=" "; print "'$src_dir'/"
>> $2}'`
>>  [ $? = 0 ] || exit 1
>>  all_includes="$all_includes $f"
>> done
>> --
>> 1.7.2.3
>
>
>

Re: [Qemu-devel] [PATCH v2] win32: Fix CRLF problem in make_device_config.sh

[Stefan Weil]

Am 18.12.2010 19:59, schrieb Blue Swirl:
> Thanks, applied.
>
> On Sat, Dec 18, 2010 at 5:09 PM, Andreas Färber 
> <andreas.faerber@web.de> 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:
>>>   Avoid using sub() and \r with awk because they are unsupported
>>>   on some platforms. Use tr to remove \r. This new solution
>>>   improves portability and was suggested by Paolo Bonzini.
>>>
>>> Signed-off-by: Stefan Weil <weil@mail.berlios.de>
>>
>> Acked-by: Andreas Färber <andreas.faerber@web.de>
>>> ---
>>> make_device_config.sh |    2 +-
>>> 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=$src
>>> while [ -n "$f" ] ; do
>>> -  f=`awk '/^include / {ORS=" " ; print "'$src_dir'/" $2}' $f`
>>> +  f=`tr -d '\r' < $f | awk '/^include / {ORS=" "; print "'$src_dir'/"
>>> $2}'`
>>>  [ $? = 0 ] || exit 1
>>>  all_includes="$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 != bash, make displays an error from 
make_device_config.sh:

$ touch default-configs/i386-softmmu.mak
$ make
   GEN   i386-softmmu/config-devices.mak
/qemu/make_device_config.sh: 24: cannot open 
/qemu/default-configs/pci.mak : 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=" ".

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="" solves the problem for me, but might raise new compatibility
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=""; print 
$2}' | od -c

It should return 0000002, not 0000003 like the previous test:

0000000   x   y
0000002

Regards,
Stefan

Re: [Qemu-devel] [PATCH v2] win32: Fix CRLF problem in make_device_config.sh

[Andreas Färber]

Am 19.12.2010 um 16:42 schrieb Stefan Weil:

> Am 18.12.2010 19:59, schrieb Blue Swirl:
>> Thanks, applied.
>>
>> On Sat, Dec 18, 2010 at 5:09 PM, Andreas Färber <andreas.faerber@web.de 
>> > 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:
>>>> Avoid using sub() and \r with awk because they are unsupported
>>>> on some platforms. Use tr to remove \r. This new solution
>>>> improves portability and was suggested by Paolo Bonzini.
>>>>
>>>> Signed-off-by: Stefan Weil <weil@mail.berlios.de>
>>>
>>> Acked-by: Andreas Färber <andreas.faerber@web.de>
>>>> ---
>>>> make_device_config.sh |    2 +-
>>>> 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=$src
>>>> while [ -n "$f" ] ; do
>>>> -  f=`awk '/^include / {ORS=" " ; print "'$src_dir'/" $2}' $f`
>>>> +  f=`tr -d '\r' < $f | awk '/^include / {ORS=" "; print  
>>>> "'$src_dir'/"
>>>> $2}'`
>>>> [ $? = 0 ] || exit 1
>>>> all_includes="$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 != bash, make displays an error from  
> make_device_config.sh:
>
> $ touch default-configs/i386-softmmu.mak
> $ make
> GEN   i386-softmmu/config-devices.mak
> /qemu/make_device_config.sh: 24: cannot open /qemu/default-configs/ 
> pci.mak : No such file
>
> make continues, so the error message is not fatal but a cosmetical  
> issue.

I'm pretty sure I saw that with some bash, too. Possibly on Haiku.  
Anyway...

> 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=" ".
>
> 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="" solves the problem for me, but might raise new  
> compatibility
> 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="";  
> print $2}' | od -c
>
> It should return 0000002, not 0000003 like the previous test:
>
> 0000000   x   y
> 0000002

Tested-by: Andreas Färber <andreas.faerber@web.de>

Re: [Qemu-devel] [PATCH v2] win32: Fix CRLF problem in make_device_config.sh

[Blue Swirl]

On Sun, Dec 19, 2010 at 3:42 PM, Stefan Weil <weil@mail.berlios.de> wrote:
> Am 18.12.2010 19:59, schrieb Blue Swirl:
>>
>> Thanks, applied.
>>
>> On Sat, Dec 18, 2010 at 5:09 PM, Andreas Färber <andreas.faerber@web.de>
>> 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:
>>>>  Avoid using sub() and \r with awk because they are unsupported
>>>>  on some platforms. Use tr to remove \r. This new solution
>>>>  improves portability and was suggested by Paolo Bonzini.
>>>>
>>>> Signed-off-by: Stefan Weil <weil@mail.berlios.de>
>>>
>>> Acked-by: Andreas Färber <andreas.faerber@web.de>
>>>>
>>>> ---
>>>> make_device_config.sh |    2 +-
>>>> 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=$src
>>>> while [ -n "$f" ] ; do
>>>> -  f=`awk '/^include / {ORS=" " ; print "'$src_dir'/" $2}' $f`
>>>> +  f=`tr -d '\r' < $f | awk '/^include / {ORS=" "; print "'$src_dir'/"
>>>> $2}'`
>>>>  [ $? = 0 ] || exit 1
>>>>  all_includes="$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 != bash, make displays an error from
> make_device_config.sh:
>
> $ touch default-configs/i386-softmmu.mak
> $ make
>  GEN   i386-softmmu/config-devices.mak
> /qemu/make_device_config.sh: 24: cannot open /qemu/default-configs/pci.mak :
> 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=" ".
>
> 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="" solves the problem for me, but might raise new compatibility
> 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=""; print $2}'
> | od -c
>
> It should return 0000002, not 0000003 like the previous test:
>
> 0000000   x   y
> 0000002

How about something like this instead:
(SRC_DIR=/src; echo -e 'include xy' | sed -n 's|^include
*\(.*\)|'$SRC_DIR/'\1|p')
/src/xy

Re: [Qemu-devel] [PATCH v2] win32: Fix CRLF problem in make_device_config.sh

[Andreas Färber]

Am 19.12.2010 um 17:21 schrieb Blue Swirl:

> On Sun, Dec 19, 2010 at 3:42 PM, Stefan Weil <weil@mail.berlios.de>  
> wrote:
>> Am 18.12.2010 19:59, schrieb Blue Swirl:
>>>
>>> Thanks, applied.
>>>
>>> On Sat, Dec 18, 2010 at 5:09 PM, Andreas Färber <andreas.faerber@web.de 
>>> >
>>> 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:
>>>>>  Avoid using sub() and \r with awk because they are unsupported
>>>>>  on some platforms. Use tr to remove \r. This new solution
>>>>>  improves portability and was suggested by Paolo Bonzini.
>>>>>
>>>>> Signed-off-by: Stefan Weil <weil@mail.berlios.de>
>>>>
>>>> Acked-by: Andreas Färber <andreas.faerber@web.de>
>>>>>
>>>>> ---
>>>>> make_device_config.sh |    2 +-
>>>>> 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=$src
>>>>> while [ -n "$f" ] ; do
>>>>> -  f=`awk '/^include / {ORS=" " ; print "'$src_dir'/" $2}' $f`
>>>>> +  f=`tr -d '\r' < $f | awk '/^include / {ORS=" "; print  
>>>>> "'$src_dir'/"
>>>>> $2}'`
>>>>>  [ $? = 0 ] || exit 1
>>>>>  all_includes="$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 != bash, make displays an error from
>> make_device_config.sh:
>>
>> $ touch default-configs/i386-softmmu.mak
>> $ make
>>  GEN   i386-softmmu/config-devices.mak
>> /qemu/make_device_config.sh: 24: cannot open /qemu/default-configs/ 
>> pci.mak :
>> 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=" ".
>>
>> 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="" solves the problem for me, but might raise new  
>> compatibility
>> 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="";  
>> print $2}'
>> | od -c
>>
>> It should return 0000002, not 0000003 like the previous test:
>>
>> 0000000   x   y
>> 0000002
>
> How about something like this instead:
> (SRC_DIR=/src; echo -e 'include xy' | sed -n 's|^include
> *\(.*\)|'$SRC_DIR/'\1|p')
> /src/xy

Produces the above result on Sol10. With 'include xy\r' ... | od -c  
leads to:

0000000   /   s   r   c   /   x   y   \r  \n
0000011

In bash.

Re: [Qemu-devel] [PATCH v2] win32: Fix CRLF problem in make_device_config.sh

[Paolo Bonzini]

On 12/19/2010 05:06 PM, Andreas Färber wrote:
>
> Andreas, may I ask you for one more test?
>
> $ echo -e 'include xy\r' | tr -d '\r' | awk '/^include / {ORS=""; print
> $2}' | od -c

I'd not bother with ORS and use '$1 == "include" { printf "%s", $2 }' 
instead.

Paolo

Re: [Qemu-devel] [PATCH v2] win32: Fix CRLF problem in make_device_config.sh

[Andreas Färber]

Am 19.12.2010 um 17:06 schrieb Andreas Färber:

> Am 19.12.2010 um 16:42 schrieb Stefan Weil:
>
>> Am 18.12.2010 19:59, schrieb Blue Swirl:
>>> Thanks, applied.
>>>
>>> On Sat, Dec 18, 2010 at 5:09 PM, Andreas Färber <andreas.faerber@web.de 
>>> > 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:
>>>>> Avoid using sub() and \r with awk because they are unsupported
>>>>> on some platforms. Use tr to remove \r. This new solution
>>>>> improves portability and was suggested by Paolo Bonzini.
>>>>>
>>>>> Signed-off-by: Stefan Weil <weil@mail.berlios.de>
>>>>
>>>> Acked-by: Andreas Färber <andreas.faerber@web.de>
>>>>> ---
>>>>> make_device_config.sh |    2 +-
>>>>> 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=$src
>>>>> while [ -n "$f" ] ; do
>>>>> -  f=`awk '/^include / {ORS=" " ; print "'$src_dir'/" $2}' $f`
>>>>> +  f=`tr -d '\r' < $f | awk '/^include / {ORS=" "; print  
>>>>> "'$src_dir'/"
>>>>> $2}'`
>>>>> [ $? = 0 ] || exit 1
>>>>> all_includes="$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 != bash, make displays an error from  
>> make_device_config.sh:
>>
>> $ touch default-configs/i386-softmmu.mak
>> $ make
>> GEN   i386-softmmu/config-devices.mak
>> /qemu/make_device_config.sh: 24: cannot open /qemu/default-configs/ 
>> pci.mak : No such file
>>
>> make continues, so the error message is not fatal but a cosmetical  
>> issue.
>
> I'm pretty sure I saw that with some bash, too. Possibly on Haiku.

I'm still seeing this issue, on Mac OS X with bash. And yes, on Haiku  
with bash, too.

Any update?

Thanks,
Andreas

> Anyway...
>
>> 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=" ".
>>
>> 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="" solves the problem for me, but might raise new  
>> compatibility
>> 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="";  
>> print $2}' | od -c
>>
>> It should return 0000002, not 0000003 like the previous test:
>>
>> 0000000   x   y
>> 0000002
>
> Tested-by: Andreas Färber <andreas.faerber@web.de>

[Qemu-devel] [PATCH] make_device_config: Fix non-fatal error message with dash and other shells

[Stefan Weil]

ORS=" " adds a blank to the name of the include file.
Some shells (e.g. dash) don't accept input redirection
(tr -d '\r' < $f) when $f ends with a blank, so they
print an error message instead of reading pci.mak.
This is a non-fatal error because pci.mak does not
contain an include line. It was introduced by commit
5d6b423c5cd6f9dfac30959ff1d5c088996719c3.

Using printf avoids adding a blank and is also supported
by older awk versions (this solution was suggested by
Paolo Bonzini, thank you).

Cc: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
---
 make_device_config.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/make_device_config.sh b/make_device_config.sh
index 596fc5b..5d14885 100644
--- a/make_device_config.sh
+++ b/make_device_config.sh
@@ -18,7 +18,7 @@ process_includes () {
 
 f=$src
 while [ -n "$f" ] ; do
-  f=`tr -d '\r' < $f | awk '/^include / {ORS=" "; print "'$src_dir'/" $2}'`
+  f=`tr -d '\r' < $f | awk '/^include / {printf "'$src_dir'/%s", $2}'`
   [ $? = 0 ] || exit 1
   all_includes="$all_includes $f"
 done
-- 
1.7.2.3

Re: [Qemu-devel] [PATCH] make_device_config: Fix non-fatal error message with dash and other shells

[Andreas Färber]

Am 30.12.2010 um 23:04 schrieb Stefan Weil:

> ORS=" " adds a blank to the name of the include file.
> Some shells (e.g. dash) don't accept input redirection
> (tr -d '\r' < $f) when $f ends with a blank, so they
> print an error message instead of reading pci.mak.
> This is a non-fatal error because pci.mak does not
> contain an include line. It was introduced by commit
> 5d6b423c5cd6f9dfac30959ff1d5c088996719c3.
>
> Using printf avoids adding a blank and is also supported
> by older awk versions (this solution was suggested by
> Paolo Bonzini, thank you).
>
> Cc: Blue Swirl <blauwirbel@gmail.com>
> Signed-off-by: Stefan Weil <weil@mail.berlios.de>

Tested-by: Andreas Färber <andreas.faerber@web.de>

`make defconfig; make` working fine on Mac OS X now!

Thanks,
Andreas

> ---
> make_device_config.sh |    2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/make_device_config.sh b/make_device_config.sh
> index 596fc5b..5d14885 100644
> --- a/make_device_config.sh
> +++ b/make_device_config.sh
> @@ -18,7 +18,7 @@ process_includes () {
>
> f=$src
> while [ -n "$f" ] ; do
> -  f=`tr -d '\r' < $f | awk '/^include / {ORS=" "; print  
> "'$src_dir'/" $2}'`
> +  f=`tr -d '\r' < $f | awk '/^include / {printf "'$src_dir'/%s",  
> $2}'`
>   [ $? = 0 ] || exit 1
>   all_includes="$all_includes $f"
> done
> -- 
> 1.7.2.3
>
>