Re: bash kill(1) doesn't report errors when $(ulimit -i) is exceeded
On Tue, Jul 16, 2013 at 11:12 PM, Linus Torvalds wrote: > On Tue, Jul 16, 2013 at 1:31 PM, Lionel Cons wrote: >> >> Either your ulimit -i is greater than 63000 or we have a Linux bug. If >> ulimit -i is reached then kill(1) should fail. > > Traditionally kill() has never returned errors for things like this. > In fact, quite arguably POSIX actively disallows kill() from returning > errors for queue overflow: "The kill() function is successful if the > process has permission to send sig to any of the processes specified > by pid. If kill() fails, no signal shall be sent." > > Notice how "is successful" is not dependent on whether a signal was > sent or not, it is dependent on whether you have _permission_ to send > the signal to the specified process. > > Now, I don't think "POSIX requires" is all that big a deal, and > there's a lot of gray areas where POSIX just doesn't talk about > everything that could go wrong. So I don't think the above is a very > strong argument for not possibly changing semantics, but I do argue > that it's an argument for what traditional behavior is. > > I think you could quite validly argue for changing the Linux kernel > semantics, but it has to come from that direction: talk about why you > need it, show that it doesn't break other applications, maybe study > what different versions of Unix actually do or don't do wrt this. But > for Linux you'd need to do it on the kernel mailing list and probably > particularly with the people involved in the whole signal semantics > (Oleg Nesterov, Al Viro, Andrew Morton, with me probably cc'd). And > if you have a patch, that obviously would be a great addition to that > discussion too. I think that Linux is wrong here: It should never fail if a signal can't be send. It'll break too much stuff if that happens. Sadly, Linux does exactly that, and it only happens when the system is under stress, i.e. when memory is scare. Josh
Re: Bash-4.3-beta2 available for FTP
On Sat, Oct 12, 2013 at 8:34 PM, Cedric Blancher
wrote:
> On 7 October 2013 02:14, Chet Ramey wrote:
>> The second beta release of bash-4.3 is now available with the URL
>>
>> ftp://ftp.cwru.edu/pub/bash/bash-4.3-beta2.tar.gz
>>
>> This tar file does not include the formatted documentation (you
>> should be able to generate it yourself).
>>
>> This release fixes many outstanding bugs in bash-4.2 and introduces several
>> new features. The most significant bug fix is the reworking of signal
>> handling to avoid running signal and trap handlers in a signal handler
>> context. This led to issues with glibc, which uses internal locks
>> extensively and handles longjmps from user code very poorly.
>>
>> The most notable new features are the `globasciiranges' shell option, which
>> forces the pattern matching code to treat [a-z] as if in the C locale;
>> nameref variables and the changes to allow assigning, referencing, and
>> unsetting them; improvements to the `direxpand' option introduced in bash-4.2
>> patch 29; and allowing negative subscripts when assigning and referencing
>> indexed array elements.
>>
>> There is one incompatible change between bash-4.2 and bash-4.3. Bash now
>> performs quote removal on the replacement string in pattern substitution
>> (${param/pat/rep}), since the shell treats quotes as special. If you
>> have to quote single quotes to get them to be treated literally, the shell
>> should perform quote removal on them.
>>
>> `bashbug' may be used to report bugs with this version. It will send
>> mail to c...@po.cwru.edu if the shell's `release status' is alpha or
>> beta.
>>
>> As always, thanks for your help.
>>
>> Chet
>>
>> +== CHANGES ==+
>> This document details the changes between this version, bash-4.3-beta2, and
>> the
>> previous version, bash-4.3-beta.
>
> What happened to the patch for cd -@ to handle NFSv4+Windows alternate
> streams? ksh93 already has this feature since quite some time and
> they're now even extending support even further to the builtin POSIX
> commands...
Do you mean cd -@ as this one in ksh?
- - - - - - - -
-@ Change into the hidden attribute directory of directory which
may also be a file. CDPATH is ignored. Hidden attribute
directories are file system and operating system specific.
- - - - - - - -
That would be great. Where's the patch?
Josh
Re: Bash-4.3-beta2 available for FTP
On Sat, Oct 12, 2013 at 10:14 PM, Joshuah Hurst wrote:
> On Sat, Oct 12, 2013 at 8:34 PM, Cedric Blancher
> wrote:
>> On 7 October 2013 02:14, Chet Ramey wrote:
>>> The second beta release of bash-4.3 is now available with the URL
>>>
>>> ftp://ftp.cwru.edu/pub/bash/bash-4.3-beta2.tar.gz
>>>
>>> This tar file does not include the formatted documentation (you
>>> should be able to generate it yourself).
>>>
>>> This release fixes many outstanding bugs in bash-4.2 and introduces several
>>> new features. The most significant bug fix is the reworking of signal
>>> handling to avoid running signal and trap handlers in a signal handler
>>> context. This led to issues with glibc, which uses internal locks
>>> extensively and handles longjmps from user code very poorly.
>>>
>>> The most notable new features are the `globasciiranges' shell option, which
>>> forces the pattern matching code to treat [a-z] as if in the C locale;
>>> nameref variables and the changes to allow assigning, referencing, and
>>> unsetting them; improvements to the `direxpand' option introduced in
>>> bash-4.2
>>> patch 29; and allowing negative subscripts when assigning and referencing
>>> indexed array elements.
>>>
>>> There is one incompatible change between bash-4.2 and bash-4.3. Bash now
>>> performs quote removal on the replacement string in pattern substitution
>>> (${param/pat/rep}), since the shell treats quotes as special. If you
>>> have to quote single quotes to get them to be treated literally, the shell
>>> should perform quote removal on them.
>>>
>>> `bashbug' may be used to report bugs with this version. It will send
>>> mail to c...@po.cwru.edu if the shell's `release status' is alpha or
>>> beta.
>>>
>>> As always, thanks for your help.
>>>
>>> Chet
>>>
>>> +== CHANGES ==+
>>> This document details the changes between this version, bash-4.3-beta2, and
>>> the
>>> previous version, bash-4.3-beta.
>>
>> What happened to the patch for cd -@ to handle NFSv4+Windows alternate
>> streams? ksh93 already has this feature since quite some time and
>> they're now even extending support even further to the builtin POSIX
>> commands...
>
> Do you mean cd -@ as this one in ksh?
> - - - - - - - -
> -@ Change into the hidden attribute directory of directory
> which
> may also be a file. CDPATH is ignored. Hidden attribute
> directories are file system and operating system specific.
> - - - - - - - -
>
> That would be great. Where's the patch?
Just to be sure, this does use the extended attributes with O_XATTR, right?
Josh
Re: Bash-4.3-beta2 available for FTP
On Tue, Oct 15, 2013 at 10:36 PM, Chet Ramey wrote: > On 10/15/13 4:27 PM, Joshuah Hurst wrote: > >>>> What happened to the patch for cd -@ to handle NFSv4+Windows alternate >>>> streams? ksh93 already has this feature since quite some time and >>>> they're now even extending support even further to the builtin POSIX >>>> commands... > > I have not added it to bash yet. How long does it take? > >>> >>> Do you mean cd -@ as this one in ksh? >>> - - - - - - - - >>> -@ Change into the hidden attribute directory of directory >>> which >>> may also be a file. CDPATH is ignored. Hidden attribute >>> directories are file system and operating system specific. >>> - - - - - - - - >>> >>> That would be great. Where's the patch? >> >> Just to be sure, this does use the extended attributes with O_XATTR, right? > > Yes, Cedric's patch uses O_XATTR. *Great*! :) Chester/Cedric: Can you send the patch around so we can ask the Debian GNU/kOpenSolaris, Solaris and Illumos folks to integrate the patch in their next bash patch update, please? Josh
[bug] Problem with cd -@ if filesystem does not support extended attributes (O_XATTR)
Chet, on Solaris the /devices filesystem does not support extended
attributes (O_XATTR), yet cd -@ returns 0 (success):
./bash -c 'cd -@ /devices 2>/dev/null; echo $?'
0
~/bin/ksh -c 'cd -@ /devices 2>/dev/null; echo $?'
1
truss shows that bash gets errno==EINVAL but then uses
chdir("/devices") instead of returning the error:
stat64("/devices", 0x08047520) = 0
open64("/devices", O_RDONLY|O_NONBLOCK) = 3
openat64(3, ".", O_RDONLY|O_XATTR) Err#22 EINVAL
close(3)= 0
chdir("/devices") = 0
brk(0x0819C000) = 0
Josh
-- Forwarded message --
From: Lionel Cons
Date: Tue, Nov 5, 2013 at 11:12 PM
Subject: Re: Bash-4.3-beta2 available for FTP
To: Chester Ramey
Cc: Simon Toedt , bug-bash@gnu.org, Joshuah
Hurst , Cedric Blancher
, Chester Ramey
On 5 November 2013 22:56, Chet Ramey wrote:
>> > I'm interested in the patch if cd -@ file works like in ksh. Or
>> > whatever, just send the patch that I can test it.
>> >
>> > Thank you.
>>
>> Again. Any patch or git pull tarball which we could try?
>
> The cd -@ option is available in the `devel' branch of the git tree on
> savannah:
>
> http://git.savannah.gnu.org/cgit/bash.git/?h=devel
>
> It first appears in the bash-20131025 snapshot.
Chet, thank you
Build instructions:
git clone --branch devel git://git.savannah.gnu.org/bash.git
Apply this patch and then build as usual:
diff --git a/builtins/cd.def b/builtins/cd.def
index 498cf88..c448c5a 100644
--- a/builtins/cd.def
+++ b/builtins/cd.def
@@ -194,7 +194,7 @@ cdxattr (dir, ndirp)
{
#if defined (O_XATTR)
int apfd, fd, r, e;
- char buf[11+40+40]; /* construct new `fake' path for pwd */
+ char buff[11+40+40]; /* construct new `fake' path for pwd */
apfd = openat (AT_FDCWD, dir, O_RDONLY|O_NONBLOCK);
if (apfd < 0)
Lionel
--
Josh
Re: Testcase for cd -@ / O_XATTR
On Thu, Nov 7, 2013 at 8:53 PM, Chet Ramey wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/6/13 10:34 PM, Chris Down wrote: >> On 2013-11-06 22:23:41 -0500, Chet Ramey wrote: >>> I'll think about it. I generally don't like to add test cases for features >>> that are available on so few platforms. >> >> Why? Surely that is the place where such test cases would be most >> valuable? > > Sure. It just generates spurious results on platforms that don't support > the feature. Why? You could test whether a platform supports the cd -@ option based on the cd --help output and only run the test if -@ is a supported option. Josh
