Re: [opensuse-factory] why are raw scripts forced into /bin/sh instead of user's shell (a Suse patch to bash)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
В Fri, 1 Mar 2013 00:57:16 +0100 (CET)
"Carlos E. R."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-02-27 a las 22:52 -0600, Larry Finger escribió:
On 02/27/2013 09:59 PM, Linda Walsh wrote:
Why do you think this is SUSE only. Every distro has a default shell, which is what you get when you do not specify the shell to use.
/bin/sh is a link to a shell. Linda, find out which it is in your system.
You miss the point. The upstream bash invokes script using the same name under which it has been started: /* The name of this shell, as taken from argv[0]. */ char *shell_name = (char *)NULL; (open?)SUSE patch forces script to always run with /bin/sh There must be some reason why it was changed. I would be interested to know it too. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlEwF54ACgkQR6LMutpd94wrDgCcCdOTNJGZAegMN5H2T0+Nk8IB wtkAn1FVG4c9x9EGjupdSodQVL/mPupE =RkvE -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
В Fri, 1 Mar 2013 00:57:16 +0100 (CET) "Carlos E. R."
пишет: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-02-27 a las 22:52 -0600, Larry Finger escribió:
On 02/27/2013 09:59 PM, Linda Walsh wrote:
Why do you think this is SUSE only. Every distro has a default shell, which is what you get when you do not specify the shell to use.
/bin/sh is a link to a shell. Linda, find out which it is in your system.
You miss the point. The upstream bash invokes script using the same name under which it has been started:
/* The name of this shell, as taken from argv[0]. */ char *shell_name = (char *)NULL;
(open?)SUSE patch forces script to always run with /bin/sh
There must be some reason why it was changed. I would be interested to know it too.
On 03/01/2013 03:51 AM, Andrey Borzenkov wrote: the patch changing this is bash-3.2-longjmp.dif. and the changes entry is: Wed Mar 9 12:00:48 CET 2011 - werner@suse.de - Avoid siglongjmp, compare with http://lists.gnu.org/archive/html/bug-bash/2011-03/msg00070.html use temprary solution from Chet Chet is the upstream bash author. Might need to be revisited... Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Andreas Jaeger
/* The name of this shell, as taken from argv[0]. */ char *shell_name = (char *)NULL;
(open?)SUSE patch forces script to always run with /bin/sh
There must be some reason why it was changed. I would be interested to know it too. the patch changing this is bash-3.2-longjmp.dif.
I am not sure whether you know this, but bash-3.x is definitely not POSIX compatible as it misshandles "sh -ce 'command...'" which is needed for correct make(1) behavior. As a result, make runs may not stop on errors. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Mar 01, 2013 at 10:47:10AM +0100, Andreas Jaeger wrote:
El 2013-02-27 a las 22:52 -0600, Larry Finger escribió:
On 02/27/2013 09:59 PM, Linda Walsh wrote:
Why do you think this is SUSE only. Every distro has a default shell, which is what you get when you do not specify the shell to use.
/bin/sh is a link to a shell. Linda, find out which it is in your system.
You miss the point. The upstream bash invokes script using the same name under which it has been started:
/* The name of this shell, as taken from argv[0]. */ char *shell_name = (char *)NULL;
(open?)SUSE patch forces script to always run with /bin/sh
There must be some reason why it was changed. I would be interested to know it too. the patch changing this is bash-3.2-longjmp.dif.
and the changes entry is: Wed Mar 9 12:00:48 CET 2011 - werner@suse.de
- Avoid siglongjmp, compare with http://lists.gnu.org/archive/html/bug-bash/2011-03/msg00070.html use temprary solution from Chet
Chet is the upstream bash author.
Might need to be revisited...
Sorry but this is wrong. The change for siglongjmp() versus set longjmp() has nothing todo with this patch. The patch belongs to memory corruption ahd happen with several bug reports like: http://bugzilla.novell.com/show_bug.cgi?id=382214 http://bugzilla.novell.com/show_bug.cgi?id=384175 that is that after the siglongjmp() the bash had showed memory corruption. This seems to be fixed in bash 4.2 ... nevertheless it could come back again as memory management together with setjmp()/longjmp() or sigsetjmp()/siglongjmp() has to managed thorough to not run into the same problems as in the bugs above. This is the only reason why this patch is still alive. And yes I've read the thread http://www.mail-archive.com/bug-bash@gnu.org/msg12269.html Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dr. Werner Fink wrote:
http://bugzilla.novell.com/show_bug.cgi?id=382214 http://bugzilla.novell.com/show_bug.cgi?id=384175
that is that after the siglongjmp() the bash had showed memory corruption. This seems to be fixed in bash 4.2 ... nevertheless it could come back again as memory management together with setjmp()/longjmp() or sigsetjmp()/siglongjmp() has to managed thorough to not run into the same problems as in the bugs above.
This is the only reason why this patch is still alive.
---- So you are saying that outdated patches that are not solving any current problem should be kept in the code because they might solve some future problem? Do you know how many problems there have been in linux SW? Why would you not carry around patches for all previous problems on the same reasoning: that they might reoccur? Sounds a bit like the specious reasoning SuSE disables parallel CPU usage in sort when that is the default -- early algorithms had problems, that are no longer there, but SuSE's disabling of parallel sort is still in there by default. How many patches are in suse code for things that are no longer valid? Isn't that more likely to create new problems as that list grows? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dr. Werner Fink wrote:
On Fri, Mar 01, 2013 at 10:47:10AM +0100, Andreas Jaeger wrote:
Sorry but this is wrong. The change for siglongjmp() versus set longjmp() has nothing todo with this patch. The patch belongs to memory corruption ahd happen with several bug reports like:
http://bugzilla.novell.com/show_bug.cgi?id=382214 http://bugzilla.novell.com/show_bug.cgi?id=384175
The first was 5 years ago in version 3.2 the 2nd is closed off as private. 4.2 is very different from 3.2. Why would you keep a patch for a 5 year old piece of software in a new version that has had no reports with it? Also, I find out that openSuSE was the only vendor that had problems with this. That would indicate it's likely do to some other, even older patch that has created the problem. Maybe removing outdated patches should prioritized a bit higher in the next release cycle? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Andreas Jaeger
-
Andrey Borzenkov
-
Dr. Werner Fink
-
Joerg Schilling
-
Linda Walsh