Re: Status of pipefail for standardization
Date:Sat, 15 Sep 2018 19:54:20 -0400 From:Chet Ramey Message-ID: <6236131b-b65d-7d08-c48a-fbca06fc2...@case.edu> | The chance of this happening in the future, when it has not happened | so far, is vanishingly small. I agree that it would be very rare, which is exactly why now, it doesn't really matter which way it gets defined. But I'm sue you've run into users who just love to push the envelope and do the wierdest things, which no-one had ever attempted before - having good, clear, definitions helps avoid problems in those cases. | We'll see how it goes. It took a #define and three lines of code. Great, thanks, and yes, that's just about the same as it took me .. define a new flag, set it appropriately (from pipefail) when creating the job, and then use that rather than the pipefail opt value when collecting the status. Boringly simple, and, as above, really unlikely to bother any current users, and makes for a much more predictable outcome when someone does decide to do something bizarre. kre
Re: Status of pipefail for standardization
On 9/11/18 4:46 PM, Robert Elz wrote: > If it is unspecified, then a script cannot start an async pipeline, > then want to run another while the first is executing, with a > different pipefail setting (different to that for the first) as as soon as > the pipefail option is changed while the async pipelline is still > running we get unspecified results from its status.That is a poor > outcome, and really, needless. If the second pipeline were also > async, then we end up with a real mess... The chance of this happening in the future, when it has not happened so far, is vanishingly small. > So, why not try changing it (without announcing any change) in > the alpha (or is it beta yet?) version of bash-5 - all of us here > will promise not to tell the "real" users, or complain about it, and > just see if there is anyone who notices. If you get complaints, > you can always change it back, if all your users are happy (ie: > they never even notice) then we will all be happy too! We'll see how it goes. It took a #define and three lines of code. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Status of pipefail for standardization
- Original Message - > From: "Joerg Schilling" > To: svashi...@redhat.com > Cc: k...@munnari.oz.au, "chet ramey" , > austin-group-l@opengroup.org > Sent: Saturday, September 15, 2018 1:23:42 PM > Subject: Re: Status of pipefail for standardization > > Siteshwar Vashisht wrote: > > > > It seems that these people are not talking with David Korn. > > > > I tried to reach dgk several times in last couple of years, but never > > managed to get a response from him. It would be great if he becomes active > > in > > the discussions again, but it's unlikely to happen. > > I know it is hard to reach him but note that he even left Google because of > the > problems he still has. > > Last time I got him (I did no try to contact him later) he answered my > questions, but it may be that he will not actively help in the development. This discussion is diverting from original topic of pipefail standardization, but still I would try to clarify few things. > > > > These people did already introduce changes that cannot be seen as an > > > improvement as they e.g. removed code and thus features that they simply > > > don't > > > understand. > > > > It was done to bring this code to more maintainable state. The way ksh is > > written makes it faster than other shells, but at the same time there are > > strange bugs hidden in it. It's a maintainer's nightmare. For example look > > at > > this bug report[1]. > > This is the wrong method. The right method is to read the source again and > again until you understand it. This is what I did with the Bourne Shell and > this helps me to understand the ksh93 source. Note that in his life before > AT, he designed supersonic wings. So he is used to think different than > most > people. You have a fair point about reading sources. > > You should not expect to be able to do in depth changes with less than 4 > years > of experience in understanding this source. The biggest change we have made is, we made it easier to build. This has only helped our cause because now people are able to build ksh easily on platforms like FreeBSD, OpenBSD etc. It was not impossible to build it earlier on these platforms but the build process was so arcane that half of the potential contributors will give up trying to build it. > > > > For us keeping ksh relevant is more important than being the fastest shell. > > This requires simplying build process, improving code quality so that mere > > mortals can contribute to it, improving documentation etc. There is no > > point > > in being the fastest shell when your code is so horrible that no new > > contributor wants to touch it. > > The korn shell source is not horrible, it just uses concepts from a person > that > is much better than the average. > > You cannot expect that people with too few programming experinces are able to > change it in a way that could be seen as an improvement. > > I created the first nearly portable Bourne Shell fork in 2006 and that added > myhistory editor from 1984 to it at that time. I started again with limited > effort in 2008 but I was not able to make in depth changes such as the > conversion to the malloc() based "stak" code code from Geoff Collyer before > 2012. I am really firm with the code since I changed it to use vfork() in > 2014. > That that time, I also changed the parser and interpreter to use a pipelne > concept where all commands in the pipeline are children of the main shell. > > > In any case, if people disagree with our ideas, they can continue to use > > last > > stable version that came out from AT (ksh9u+ i.e.), or maintain their own > > forks. > > If ksh93 is not maintained, it will loose importance, but this should not > result in quick changes. A good concept would e.g. be to introduce mandatory > code reviews for changes before they could make it into the pulic git. > > I would like to see a restart from the v- state and have code reviews for You are right about the fact we have less experience with ksh source code and we have introduced bugs while trying to improve it's code quality. But the right method is not to start from scratch with `ksh93v-`. Right method is to improve our test coverage and find defects before they get shipped into a release. And before you say it, I am not promising the next release will 100% bug free or will not have regression. All legacy softwares that I know, specially shells, have done a historically bad job at testing. I see this as an opportunity to change that. It's amazing to hear that dgk has a background in aviation, but aviation industry is known for it's insane focus on quality and testing. I see that focus missing in ksh. Why should a shell crash when compiler optimization level is changed ? > changes to that state and since I understand the ks93 source, I am available > for qualified code reviews. I agree that we need more code reviews from someone like you who has more experience with ksh source code. I could not find you on
Re: Status of pipefail for standardization
Siteshwar Vashisht wrote: > > It seems that these people are not talking with David Korn. > > I tried to reach dgk several times in last couple of years, but never > managed to get a response from him. It would be great if he becomes active in > the discussions again, but it's unlikely to happen. I know it is hard to reach him but note that he even left Google because of the problems he still has. Last time I got him (I did no try to contact him later) he answered my questions, but it may be that he will not actively help in the development. > > These people did already introduce changes that cannot be seen as an > > improvement as they e.g. removed code and thus features that they simply > > don't > > understand. > > It was done to bring this code to more maintainable state. The way ksh is > written makes it faster than other shells, but at the same time there are > strange bugs hidden in it. It's a maintainer's nightmare. For example look at > this bug report[1]. This is the wrong method. The right method is to read the source again and again until you understand it. This is what I did with the Bourne Shell and this helps me to understand the ksh93 source. Note that in his life before AT, he designed supersonic wings. So he is used to think different than most people. You should not expect to be able to do in depth changes with less than 4 years of experience in understanding this source. > For us keeping ksh relevant is more important than being the fastest shell. > This requires simplying build process, improving code quality so that mere > mortals can contribute to it, improving documentation etc. There is no point > in being the fastest shell when your code is so horrible that no new > contributor wants to touch it. The korn shell source is not horrible, it just uses concepts from a person that is much better than the average. You cannot expect that people with too few programming experinces are able to change it in a way that could be seen as an improvement. I created the first nearly portable Bourne Shell fork in 2006 and that added myhistory editor from 1984 to it at that time. I started again with limited effort in 2008 but I was not able to make in depth changes such as the conversion to the malloc() based "stak" code code from Geoff Collyer before 2012. I am really firm with the code since I changed it to use vfork() in 2014. That that time, I also changed the parser and interpreter to use a pipelne concept where all commands in the pipeline are children of the main shell. > In any case, if people disagree with our ideas, they can continue to use last > stable version that came out from AT (ksh9u+ i.e.), or maintain their own > forks. If ksh93 is not maintained, it will loose importance, but this should not result in quick changes. A good concept would e.g. be to introduce mandatory code reviews for changes before they could make it into the pulic git. I would like to see a restart from the v- state and have code reviews for changes to that state and since I understand the ks93 source, I am available for qualified code reviews. BTW: We currently have the problem that ksh93 has many deviations from the POSIX standard and if we like ksh93 to be used as a master implementation, we need to keep the quality of the source. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: Status of pipefail for standardization
Siteshwar Vashisht wrote: > > Bash and ksh93 (at least the latest version I have from git). > > > > $ ./src/cmd/ksh93/ksh -c 'type -t printf' > > builtin > > This flag was added with last beta release of ksh (ksh93v-) that came out from > AT This is related entry from changelog[1] : > > 14-07-11 +Added -t flag and -P flag to whence and type for bash compaiblity. > > Since ksh93u+ was the last release that was embraced by distributions, I would > suggest to use that as a reference. Our current work on github repo is based > on ksh93v-. Whether it was a good decision or bad is a discussion for another > day. Thank you for the hint. This release still seems to be initiated by David Korn as IIRC David left AT later. I guess this is the state that staring from late 2014 was no longer retrievable from AT as their servers suffer from a missconfiguration and die after less than a day after a restart. The v- release fixes a lot of bugs and some of them even cause core dumps. Despite the fact that it is slow when you compile it using the supplied "nmake" based environment, it could be seen as a good starting point. BTW: -a also works in this release with "type" that still is an alias to "whence v". Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: Bug 1133 find -xdev (was: Minutes of the 13th September 2018 Teleconference)
Geoff Clare wrote: > Perhaps an acceptable solution would be: > > Add -mount to find with behaviour matching nftw() FTW_MOUNT. > > Add FTW_XDEV to nftw() with behaviour matching find -xdev and pax -X. > > Make it clear that find -xdev acts on the mount points and -mount does not. It may be of interest that -xdev with the current text ha already been in SUSv2 but this was already in conflict with the find(1) implementation from Solaris that had -xdev as alias to -mount at least since 1988. > (No need to add anything to pax since you can use find ... -mount | pax > if you want the mount points excluded.) Yesterday, I added a WALK_MOUNTPLUS to my treewalker and a -mount+ primary to libfind. Depending on what we decide in the future, I later may make -xdev an alias to -mount+ or leave it as an alias to -mount. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
