headers
Jilles Tjoelker | 5 Dec 2010 18:31
Picon
Favicon

[PATCH] [EXPAND] Do not split the result of tilde expansion

A tilde expansion generates a valid pathname. Splitting it using IFS
either leaves it unchanged or changes it to something unintended.

This fixes FreeBSD sh test expansion/tilde1.0 and does not change the
outcome of the other tests.

This fixes Debian bug #601096.

Example:
  IFS=m HOME=/tmp; printf "%s\n" ~
---
 src/expand.c |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/src/expand.c b/src/expand.c
index 1b77b7c..60d4798 100644
--- a/src/expand.c
+++ b/src/expand.c
 <at>  <at>  -395,7 +395,6  <at>  <at>  done:
 	*p = c;
 	startloc = expdest - (char *)stackblock();
 	strtodest(home, SQSYNTAX, quotes);
-	recordregion(startloc, expdest - (char *)stackblock(), 0);
 	return (p);
 lose:
 	*p = c;
--

-- 
1.7.3.2

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Cristian Ionescu-Idbohrn | 15 Dec 2010 10:49
Picon
Favicon

Re: read() builtin doesnt read integer value /proc files (but bashs does)

On Sun, 28 Nov 2010, Herbert Xu wrote:
> On Sat, Sep 04, 2010 at 07:35:04PM +0000, Jilles Tjoelker wrote:
> >
> > > I attached an updated patch that corrects this pb by discarding the
> > > buffer when opening a new file.
> >
> > This discarding is still bad as it throws away valid data if the open
> > file description is shared. This happens if stdin is redirected inside a
>
> I'm with Jilles on this.  I also don't particularly feel like
> bloating dash just because of the borked /proc interface when
> there is a perfectly adequate work-around in "cat".
>
> 	value=$(cat /proc/file)

I wouldn't call that "a perfectly adequate work-around", but a painful and
unadequate work-around.  And this example will hopefully show why:

$ dash -c 'loops=10000; while [ $loops -gt 0 ];do read MAX
</proc/sys/kernel/pid_max; loops=$(($loops - 1)); done; times'
0m0.180000s 0m0.100000s
0m0.000000s 0m0.000000s

total: 0.28s

$ dash -c 'loops=10000; while [ $loops -gt 0 ];do MAX=$(cat
/proc/sys/kernel/pid_max); loops=$(($loops - 1)); done; times'
0m0.280000s 0m1.330000s
0m3.840000s 0m1.560000s
(Continue reading)

Permalink | Reply | 6 comments |
headers
Jonathan Nieder | 15 Dec 2010 19:55
Picon

Re: read() builtin doesnt read integer value /proc files (but bashs does)

Hi Cristian,

Cristian Ionescu-Idbohrn wrote:
> On Sun, 28 Nov 2010, Herbert Xu wrote:
> > On Sat, Sep 04, 2010 at 07:35:04PM +0000, Jilles Tjoelker wrote:

>>> This discarding is still bad as it throws away valid data if the open
>>> file description is shared. This happens if stdin is redirected inside a
>>
>> I'm with Jilles on this.  I also don't particularly feel like
>> bloating dash just because of the borked /proc interface when
>> there is a perfectly adequate work-around in "cat".
>>
>> 	value=$(cat /proc/file)
>
> I wouldn't call that "a perfectly adequate work-around", but a painful and
> unadequate work-around.

For what it's worth, here's what bash does (based on strace):

1. Determine whether the file is seekable.  That is, seek using
SEEK_CUR with offset 0.

2. If seekable, read a nice big chunk and then seek back to put the
file offset back in the right place.  If not seekable, read one byte
at a time.

This works in /proc because files in /proc are seekable.

That said, I don't think borked /proc is a great reason to do this
(Continue reading)

Permalink | Reply | 4 comments |
headers
Cristian Ionescu-Idbohrn | 15 Dec 2010 20:12
Picon
Favicon

Re: read() builtin doesnt read integer value /proc files (but bashs does)

Jonathan,

On Wed, 15 Dec 2010, Jonathan Nieder wrote:
> Cristian Ionescu-Idbohrn wrote:
> > On Sun, 28 Nov 2010, Herbert Xu wrote:
> >>
> >> I'm with Jilles on this.  I also don't particularly feel like
> >> bloating dash just because of the borked /proc interface when
> >> there is a perfectly adequate work-around in "cat".
> >>
> >> 	value=$(cat /proc/file)
> >
> > I wouldn't call that "a perfectly adequate work-around", but a painful
> > and unadequate work-around.
>
> This works in /proc because files in /proc are seekable.
>
> That said, I don't think borked /proc is a great reason to do this
> (it's a better reason to fix /proc).  Speeding up the read builtin
> might be a good reason.

Right.  So, there are 2 options here.  One is to to make dash work like
bash on a proc filesystem, the other to "fix" the kernel.

How many linux distributions depend on a "working" dash?
Which alternative is the more realistic one?
What are the ETAs odds?
How do we proceed?

Cheers,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jilles Tjoelker | 18 Dec 2010 23:23
Picon
Favicon

Re: read() builtin doesnt read integer value /proc files (but bashs does)

On Wed, Dec 15, 2010 at 12:55:51PM -0600, Jonathan Nieder wrote:
> Cristian Ionescu-Idbohrn wrote:
> > On Sun, 28 Nov 2010, Herbert Xu wrote:
> > > On Sat, Sep 04, 2010 at 07:35:04PM +0000, Jilles Tjoelker wrote:

> >>> This discarding is still bad as it throws away valid data if the open
> >>> file description is shared. This happens if stdin is redirected inside a

> >> I'm with Jilles on this.  I also don't particularly feel like
> >> bloating dash just because of the borked /proc interface when
> >> there is a perfectly adequate work-around in "cat".

> >> 	value=$(cat /proc/file)

> > I wouldn't call that "a perfectly adequate work-around", but a painful and
> > unadequate work-around.

> For what it's worth, here's what bash does (based on strace):

> 1. Determine whether the file is seekable.  That is, seek using
> SEEK_CUR with offset 0.

> 2. If seekable, read a nice big chunk and then seek back to put the
> file offset back in the right place.  If not seekable, read one byte
> at a time.

> This works in /proc because files in /proc are seekable.

> That said, I don't think borked /proc is a great reason to do this
> (it's a better reason to fix /proc).  Speeding up the read builtin
(Continue reading)

Permalink | Reply | 0 comments |

Gmane