How to make a file immutable in Solaris?

tudm...@onebox.com

unread,

Dec 28, 2004, 4:47:01 PM12/28/04

to

Hi, how does one go about making a file "immutable" in Solaris? I'm
looking for the Linux equivalent of chattr on Linux.

I've looked at the man pages for setacl, etc but they do not seem to do
what I am looking for.

Thanks

Rich Teer

unread,

Dec 28, 2004, 6:44:39 PM12/28/04

to

On Tue, 28 Dec 2004 tudm...@onebox.com wrote:

> Hi, how does one go about making a file "immutable" in Solaris? I'm

On current file systems, you don't. Assuming you mean immutable
in the OpenBSD way (i.e., you can't delete or change a file, but
you can add to it).

> looking for the Linux equivalent of chattr on Linux.

Man chmod. But there's still no "immutable" flag to change.

--
Rich Teer, SCNA, SCSA, author of "Solaris Systems Programming"

. * * . * .* .
. * . .*
President, * . . /\ ( . . *
Rite Online Inc. . . / .\ . * .
.*. / * \ . .
. /* o \ .
Voice: +1 (250) 979-1638 * '''||''' .
URL: http://www.rite-online.net ******************

Dave Uhring

unread,

Dec 28, 2004, 7:30:21 PM12/28/04

to

On Tue, 28 Dec 2004 23:44:39 +0000, Rich Teer wrote:

> On Tue, 28 Dec 2004 tudm...@onebox.com wrote:
>
>> Hi, how does one go about making a file "immutable" in Solaris? I'm
>
> On current file systems, you don't. Assuming you mean immutable
> in the OpenBSD way (i.e., you can't delete or change a file, but
> you can add to it).

That is just one of the flags which can be set in BSD using chflags.

arch set the archived flag
opaque set the opaque flag (owner or superuser only)
nodump set the nodump flag (owner or superuser only)
sappnd set the system append-only flag (superuser only)
schg set the system immutable flag (superuser only)
uappnd set the user append-only flag (owner or superuser only)
uchg set the user immutable flag (owner or superuser only)

Joerg Schilling

unread,

Dec 28, 2004, 8:05:50 PM12/28/04

to

In article <pan.2004.12.29....@yahoo.com>,
Dave Uhring <daveu...@yahoo.com> wrote:

>> On current file systems, you don't. Assuming you mean immutable
>> in the OpenBSD way (i.e., you can't delete or change a file, but
>> you can add to it).
>
>That is just one of the flags which can be set in BSD using chflags.
>
> arch set the archived flag
> opaque set the opaque flag (owner or superuser only)
> nodump set the nodump flag (owner or superuser only)
> sappnd set the system append-only flag (superuser only)
> schg set the system immutable flag (superuser only)
> uappnd set the user append-only flag (owner or superuser only)
> uchg set the user immutable flag (owner or superuser only)
>

Sun cannot implement this on top of UFS excelt when they would create
a shadow inode to hold the apropriate data. The UFS inode on Solaris
is completely exhausted and I believe it has been exhausted before
BSD added the flags.

I hope that Sun will implement similar functionality in ZFS.
BTW: Star supports it ;-)

--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schi...@fokus.fraunhofer.de (work) chars I am J"org Schilling
URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

Roland Mainz

unread,

Dec 29, 2004, 1:26:04 PM12/29/04

to

Joerg Schilling wrote:
> >> On current file systems, you don't. Assuming you mean immutable
> >> in the OpenBSD way (i.e., you can't delete or change a file, but
> >> you can add to it).
> >
> >That is just one of the flags which can be set in BSD using chflags.
> >
> > arch set the archived flag
> > opaque set the opaque flag (owner or superuser only)
> > nodump set the nodump flag (owner or superuser only)
> > sappnd set the system append-only flag (superuser only)
> > schg set the system immutable flag (superuser only)
> > uappnd set the user append-only flag (owner or superuser only)
> > uchg set the user immutable flag (owner or superuser only)
> >
>
> Sun cannot implement this on top of UFS excelt when they would create
> a shadow inode to hold the apropriate data. The UFS inode on Solaris
> is completely exhausted and I believe it has been exhausted before
> BSD added the flags.

;-(

Isn't it possible to (mis-)use the extended filesystem attribute support
in UFS for that somehow ? And what about NFSv3 - can it handle these
attributes, too ?

> I hope that Sun will implement similar functionality in ZFS.

Yeah, but how likely is it that such a RFE will be implemented ?

> BTW: Star supports it ;-)

1. Does the current Solaris 10 API support getting/setting these extra
flags ?
2. Solaris's "tar" and the SYSV package system need to be updated to
support these extra flags... is there anything else ?

----

Bye,
Roland

--
__ . . __
(o.\ \/ /.o) roland...@nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)

Rich Teer

unread,

Dec 29, 2004, 2:46:11 PM12/29/04

to

On Wed, 29 Dec 2004, Roland Mainz wrote:

> Yeah, but how likely is it that such a RFE will be implemented ?

With Open Solaris, you'll be able to do it yourself!

Roland Mainz

unread,

Jan 2, 2005, 1:23:51 PM1/2/05

to

Rich Teer wrote:
> > Yeah, but how likely is it that such a RFE will be implemented ?
>
> With Open Solaris, you'll be able to do it yourself!

Yeah... still the question whether Sun will ship that feature enabled
for their Solaris releases (sure, I could ship my own OpenSolaris
release then... =:-) ...

Rich Teer

unread,

Jan 2, 2005, 3:06:42 PM1/2/05

to

On Sun, 2 Jan 2005, Roland Mainz wrote:

> Yeah... still the question whether Sun will ship that feature enabled
> for their Solaris releases (sure, I could ship my own OpenSolaris

That's true. Although from what I can tell, immutable files are a
good idea, so they'd have a good chance of getting in--so long as
compaibility could be preserved, etc.

> release then... =:-) ...

Yep!

Roland Mainz

unread,

Jan 2, 2005, 5:57:25 PM1/2/05

to

Rich Teer wrote:
> > Yeah... still the question whether Sun will ship that feature enabled
> > for their Solaris releases (sure, I could ship my own OpenSolaris
>
> That's true. Although from what I can tell, immutable files are a
> good idea, so they'd have a good chance of getting in--so long as
> compaibility could be preserved, etc.

There are other good ideas which Sun could do... the problem is: Sun
doesn't do it. Just think about the (quite easy) task of shipping ksh93
with Solaris and/or fixing dtksh (since the current version is based
upon a pre-alpha version of ksh93 where even the ksh93 authors agree
that this version should have NEVER been shipped with a production
system).

John D Groenveld

unread,

Jan 2, 2005, 6:23:03 PM1/2/05

to

In article <41D87C55...@nrubsig.org>,

Roland Mainz <roland...@nrubsig.org> wrote:
>doesn't do it. Just think about the (quite easy) task of shipping ksh93
>with Solaris and/or fixing dtksh (since the current version is based

Is there an RFE for /usr/bin/ksh93?

John
groe...@acm.org

John Beck

unread,

Jan 2, 2005, 10:07:16 PM1/2/05

to

groenvel> Is there an RFE for /usr/bin/ksh93?

4113420 *ksh* request for ksh93 integration

-- John

Roland Mainz

unread,

Jan 3, 2005, 12:59:10 AM1/3/05

to

John D Groenveld wrote:
> >doesn't do it. Just think about the (quite easy) task of shipping ksh93
> >with Solaris and/or fixing dtksh (since the current version is based
>
> Is there an RFE for /usr/bin/ksh93?

Yeah, but don't ask me for the bugid. And there are tons of bug reports
about dtksh-being-broken, but it seems noone cares to update the ksh93
codebase to cure the issue (AFAIK those issues have been fixed in AIX
long ago via importing a newer version of kdh93 into the dtksh
codebase).

Roland Mainz

unread,

Jan 3, 2005, 1:17:43 AM1/3/05

to

Roland Mainz wrote:
> > >doesn't do it. Just think about the (quite easy) task of shipping ksh93
> > >with Solaris and/or fixing dtksh (since the current version is based
> >
> > Is there an RFE for /usr/bin/ksh93?
>
> Yeah, but don't ask me for the bugid.

http://www.webservertalk.com/archive100-2004-2-108862.html lists
sunsolve bugid #4990748 and bugid #4113420. Then there is a third bugid
which asks to get rid of ksh88 completely (being a nightmare) in favor
of ksh93 and various other bugids complaing about the brokeness of
dtksh.

robi...@gmail.com

unread,

Jan 3, 2005, 1:54:02 AM1/3/05

to

Roland Mainz wrote:
> Rich Teer wrote:
> > > Yeah... still the question whether Sun will ship that feature
enabled
> > > for their Solaris releases (sure, I could ship my own OpenSolaris
> >
> > That's true. Although from what I can tell, immutable files are a
> > good idea, so they'd have a good chance of getting in--so long as
> > compaibility could be preserved, etc.
>
> There are other good ideas which Sun could do... the problem is: Sun
> doesn't do it. Just think about the (quite easy) task of shipping
ksh93
> with Solaris and/or fixing dtksh (since the current version is based
> upon a pre-alpha version of ksh93 where even the ksh93 authors agree
> that this version should have NEVER been shipped with a production
> system).

AIX5L has ksh93. I'd suggest to abandon the proprietary Solaris ship
before it sinks and replace it with something sane - Linux, AIX5L, etc.
- they're all better choices than a OS which can't even update it's
korn shell to a decent version.

-- Robin

Markus Gyger

unread,

Jan 3, 2005, 4:14:57 AM1/3/05

to

John Beck <jbeck...@eng.sun.com> writes:
> groenvel> Is there an RFE for /usr/bin/ksh93?
> 4113420 *ksh* request for ksh93 integration

FYI, ksh93 recently changed its license to the CPL.
http://www.research.att.com/~gsf/download/

unread,

Jan 3, 2005, 2:14:48 PM1/3/05

to

In article <41D90D54...@nrubsig.org>,

Roland Mainz <roland...@nrubsig.org> writes:
> Markus Gyger wrote:
>> > groenvel> Is there an RFE for /usr/bin/ksh93?
>> > 4113420 *ksh* request for ksh93 integration
>>
>> FYI, ksh93 recently changed its license to the CPL.
>> http://www.research.att.com/~gsf/download/
>
> What is "CPL" ?

If you had looked at the link you were just given, you would've seen
a "Common Public License Version 1.0" link, which points
to http://www.opensource.org/licenses/cpl (but opened in a frame).

It originated with IBM, but to my eyes (ObIANAL), looks a bit like
GPL-lite minus explicit ideology preamble, plus some references to patents
(perhaps like what's rumored will be in GPL 3).

http://www.gnu.org/philosophy/license-list.html

describes it like this:

This is a free software license but it is incompatible with the GPL.

The Common Public License is incompatible with the GPL because it has
various specific requirements that are not in the GPL.

For example, it requires certain patent licenses be given that the GPL
does not require. (We don't think those patent license requirements are
inherently a bad idea, but nonetheless they are incompatible with the
GNU GPL.)

Roland Mainz

unread,

Jan 3, 2005, 3:56:26 PM1/3/05

to

Alan Coopersmith wrote:
> |Yeah, but don't ask me for the bugid. And there are tons of bug reports
> |about dtksh-being-broken, but it seems noone cares to update the ksh93
> |codebase to cure the issue (AFAIK those issues have been fixed in AIX
> |long ago via importing a newer version of kdh93 into the dtksh
> |codebase).
>
> dtksh is a dead end - there's just not enough life left in CDE support
> for a major update like that.

The "major" update consists in diffing the old version against the old
sources and then pull over the dtksh-specific bits over to the newer
ksh93 version. Someone who did the job already for another UNIX OS said
that it's less than two days of work. And there are at least two
volunteers (including myself) who are willing to sign an NDA to do the
job (if Sun is willing to ship the fix then with Solaris again). But
maybe Sun is scared of such an offer of "free" work... maybe I should
demand money for that for to make the Sun people feel more conformtable.
How much should I demand - $100, $500, $5000 ? =:-)

> Any hopes for a newer ksh would be via
> the base OS version. (If it's under an appropriate open source license,
> perhaps that could be fed in via the OpenSolaris program once it's
> going.)

Uh-oh... uh-oh... I fear the term "OpenSolaris" here... the worst-case
scenario I would expect is that someone sticks ksh93 somewhere into
/usr/swf/bin or something like that (e.g. a non-default location) where
it then rests forever.

Actually my idea was to have _ONE_ UNIFORM ksh93 installation which
consists of /usr/bin/ksh88 (old Solaris version), /usr/bin/ksh93 and
/usr/bin/ksh a softlink to the version the user preferrs. And the ksh93
version should provide /usr/lib/libshell.so.1 (and
/usr/lib/sparcv9/libshell.so.1) which are used by dtksh, Solaris dbx
(which seems to contain an own copy of the ksh88 shell) and all other
ksh version in Solaris.
Right now there are at least four Solaris applications which seem to use
all their own copies of ksh in various states (e.g. one bugfix isn't
distributed to the other versions unless a customer screams for it) -
libshell.so.1+ksh93 would cure this maintaince nightmare and provide one
uniform kornshell environment for Solaris. That would result in a huge
benefit for Sun, it's products and Sun's customers. The problem seems to
be that Sun doesn't seem to realise that there is a golden opportunity
missed here... ;-(((

Markus Gyger

unread,

Jan 9, 2005, 11:48:18 AM1/9/05

to

Richard L. Hamilton writes:
> a "Common Public License Version 1.0" link, which points
> to http://www.opensource.org/licenses/cpl (but opened in a frame).
>
> It originated with IBM, but to my eyes (ObIANAL), looks a bit like
> GPL-lite minus explicit ideology preamble, plus some references to patents
> (perhaps like what's rumored will be in GPL 3).
>
> http://www.gnu.org/philosophy/license-list.html
>
> describes it like this:
>
> This is a free software license but it is incompatible with the GPL.
>
> The Common Public License is incompatible with the GPL because it has
> various specific requirements that are not in the GPL.
>
> For example, it requires certain patent licenses be given that the GPL
> does not require. (We don't think those patent license requirements are
> inherently a bad idea, but nonetheless they are incompatible with the
> GNU GPL.)

See also http://catb.org/~esr/Licensing-HOWTO.html#comparisons
for a draft document with a comparison table (written by ESR).

Markus

Markus Gyger

unread,

Jan 9, 2005, 12:07:29 PM1/9/05

to

Roland Mainz writes:

> Alan Coopersmith wrote:
> > dtksh is a dead end - there's just not enough life left in CDE support
> > for a major update like that.
> The "major" update consists in diffing the old version against the old
> sources and then pull over the dtksh-specific bits over to the newer
> ksh93 version.

With the current version of ksh93 it would probably be more
appropriate to not modify the ksh93 source at all but to use
builtin -f (or its equivalent in libshell) to load a module
(shared library) with the dtksh commands. With that it would
probably be more work, and also ksh93 uses quite a bit a
different build mechanism than Solaris (and the dtksh source
might have been changed to fit the Solaris build mechanism,
and as well bugs in dtksh were fixed differently than in
AT&T's ksh93 tree. Nevertheless, ksh93 would be cool, also
the shared libs that come with it (e.g. a powerful regex
engine compatible to regcomp(3C) that also supports ksh
glob pattern matching, etc.). And it's actively maintained.
http://www.research.att.com/~gsf/download/

Markus

Vlad Grama

unread,

Jan 9, 2005, 3:53:29 PM1/9/05

to

Another thing that's particular to Sun's version of the integrated
shells is the "profile shell" part for using with RBAC.
A nice feature would be to have Bash integrated. All Linux users know
it. And although one can easily install bash on Solaris, it can't be
used as a profile shell. I asked about this on blogs.sun.com and they
said they would think about it..

What do you think ? Would you consider including Bash as a standard
Solaris shell a good thing (if not for yourself, to encourage Solaris
adoption by users who use this shell) ?

Vlad.

Alan Coopersmith

unread,

Jan 9, 2005, 3:57:49 PM1/9/05

to

"Vlad Grama" <vgr...@gmail.com> writes in comp.unix.solaris:

|A nice feature would be to have Bash integrated. All Linux users know
|it. And although one can easily install bash on Solaris, it can't be
|used as a profile shell. I asked about this on blogs.sun.com and they
|said they would think about it..
|
|What do you think ? Would you consider including Bash as a standard
|Solaris shell a good thing (if not for yourself, to encourage Solaris
|adoption by users who use this shell) ?

bash has been included in Solaris since Solaris 8. (Not that it helps
with the profile part.)

Joerg Schilling

unread,

Jan 9, 2005, 4:36:34 PM1/9/05

to

In article <crs5sd$dr5$1...@agate.berkeley.edu>,

Alan Coopersmith <al...@alum.calberkeley.org> wrote:
>"Vlad Grama" <vgr...@gmail.com> writes in comp.unix.solaris:
>|A nice feature would be to have Bash integrated. All Linux users know
>|it. And although one can easily install bash on Solaris, it can't be
>|used as a profile shell. I asked about this on blogs.sun.com and they
>|said they would think about it..
>|
>|What do you think ? Would you consider including Bash as a standard
>|Solaris shell a good thing (if not for yourself, to encourage Solaris
>|adoption by users who use this shell) ?
>
>bash has been included in Solaris since Solaris 8. (Not that it helps
>with the profile part.)

I believe that it was a good idea to include bash. Making it the default shell
is a bad idea as bash has a lot of nasty bugs.

Alan Coopersmith

unread,

Jan 9, 2005, 4:40:40 PM1/9/05

to

Markus Gyger <marku...@gyger.org> writes in comp.unix.solaris:

|(shared library) with the dtksh commands. With that it would
|probably be more work, and also ksh93 uses quite a bit a
|different build mechanism than Solaris (and the dtksh source
|might have been changed to fit the Solaris build mechanism,

There is no one Solaris build mechanism - it's built by combining
packages from different groups using the build mechanisms most
appropriate for them. For X & CDE, that's Imake-based, for GNOME,
that's GNU autotools, etc. The ksh portions of dtksh though use
the original, "unique" build mechanism that I believe came originally
from ksh88.

Alan Coopersmith

unread,

Jan 9, 2005, 4:47:20 PM1/9/05

to

Roland Mainz <roland...@nrubsig.org> writes in comp.unix.solaris:

|The "major" update consists in diffing the old version against the old
|sources and then pull over the dtksh-specific bits over to the newer
|ksh93 version. Someone who did the job already for another UNIX OS said
|that it's less than two days of work. And there are at least two
|volunteers (including myself) who are willing to sign an NDA to do the
|job (if Sun is willing to ship the fix then with Solaris again). But
|maybe Sun is scared of such an offer of "free" work... maybe I should
|demand money for that for to make the Sun people feel more conformtable.

I doubt anyone's afraid of "free" work - if they were, OpenSolaris
wouldn't be happening. Unfortunately, CDE is not yet part of
the source released via OpenSolaris and I don't know if/when it will be.
(They're starting at the core, similar to what was previously released
as the "Foundation Source" program, and working their way out from
there.)

|> Any hopes for a newer ksh would be via
|> the base OS version. (If it's under an appropriate open source license,
|> perhaps that could be fed in via the OpenSolaris program once it's
|> going.)
|
|Uh-oh... uh-oh... I fear the term "OpenSolaris" here...

Why? It would allow you to get the changes you want into the Solaris
base for future releases.

Markus Gyger

unread,

Jan 9, 2005, 4:46:33 PM1/9/05

to

Vlad Grama writes:
> A nice feature would be to have Bash integrated. All Linux users know
> it. And although one can easily install bash on Solaris, it can't be
> used as a profile shell.

It's probably not too difficult to add it yourself (I've
done it for ksh93 but I've simply disabled the module load
mechanism when -P is used, so you can't use the faster
builtin commands of libcmd). I suspect the issue is more
likely that a profile shell has to be maintained a bit more
carefully.

Markus

Joerg Schilling

unread,

Jan 10, 2005, 5:23:08 AM1/10/05

to

In article <crs8co$g7f$1...@agate.berkeley.edu>,
Alan Coopersmith <al...@alum.calberkeley.org> wrote:

>There is no one Solaris build mechanism - it's built by combining
>packages from different groups using the build mechanisms most
>appropriate for them. For X & CDE, that's Imake-based, for GNOME,
>that's GNU autotools, etc. The ksh portions of dtksh though use
>the original, "unique" build mechanism that I believe came originally
>from ksh88.

If this is true, then things must have changed recently.

About one year ago, I have been told that not a single FSF program
is allowed to be part of the build environment for Solaris and that
Sun needs to create a new build environment for my tools that are included
with Solaris.

Roland Mainz

unread,

Jan 10, 2005, 7:46:57 AM1/10/05

to

Markus Gyger wrote:
> > > dtksh is a dead end - there's just not enough life left in CDE support
> > > for a major update like that.
> > The "major" update consists in diffing the old version against the old
> > sources and then pull over the dtksh-specific bits over to the newer
> > ksh93 version.
>
> With the current version of ksh93 it would probably be more
> appropriate to not modify the ksh93 source at all but to use
> builtin -f (or its equivalent in libshell) to load a module
> (shared library) with the dtksh commands.

That's not really possible - dtksh needs some hooks to ksh internals.
However the differences are minor and a dtksh can share common parts
with normal ksh93 via libshell.so ...

Roland Mainz

unread,

Jan 10, 2005, 7:49:18 AM1/10/05

to

Ugh. Current bash is a nightmare. No associative arrays, no i18n support
beyond UTF-8 (well, there is bash3 - but that version isn't mature yet)
and many other ksh/ksh93 goodies are missing.
And bash is an ugly resource hog - it fetches nearly twice as much
memory than the same shell sesssion under ksh93.

Roland Mainz

unread,

Jan 10, 2005, 7:56:33 AM1/10/05

to

Alan Coopersmith wrote:
> |The "major" update consists in diffing the old version against the old
> |sources and then pull over the dtksh-specific bits over to the newer
> |ksh93 version. Someone who did the job already for another UNIX OS said
> |that it's less than two days of work. And there are at least two
> |volunteers (including myself) who are willing to sign an NDA to do the
> |job (if Sun is willing to ship the fix then with Solaris again). But
> |maybe Sun is scared of such an offer of "free" work... maybe I should
> |demand money for that for to make the Sun people feel more conformtable.
>
> I doubt anyone's afraid of "free" work - if they were, OpenSolaris
> wouldn't be happening. Unfortunately, CDE is not yet part of
> the source released via OpenSolaris and I don't know if/when it will be.
> (They're starting at the core, similar to what was previously released
> as the "Foundation Source" program, and working their way out from
> there.)

I wasn't thinking about the OpenSolaris program here. I was thinking
about signing an NDA, getting the damn source from Sun, fixing it and
then submit the patch back for integration into Solaris 10 (for the log:
It's dtksh in Solaris 10 which makes me worry, previous releases where
not that bad except that they're based in sources more than a decade old
(or something like that)).

> |> Any hopes for a newer ksh would be via
> |> the base OS version. (If it's under an appropriate open source license,
> |> perhaps that could be fed in via the OpenSolaris program once it's
> |> going.)
> |
> |Uh-oh... uh-oh... I fear the term "OpenSolaris" here...
>
> Why? It would allow you to get the changes you want into the Solaris
> base for future releases.

See my other comments in my posting. I fear that someone "fixes" the bug
"ksh93-is-missing" via sticking it into a non-default localion (e.g.
/usr/sfw/ etc.) where it then sticks forever. This is what I am worrying
about. ksh93 should reside at /usr/bin/ksh93 (and /usr/bin/ksh if anyone
at Sun can open their heart for that) and /usr/lib/libshell.so.1, not
some weired free-but-unsupported-software-dir.

Roland Mainz

unread,

Jan 10, 2005, 7:57:28 AM1/10/05

to

Joerg Schilling wrote:
> >"Vlad Grama" <vgr...@gmail.com> writes in comp.unix.solaris:
> >|A nice feature would be to have Bash integrated. All Linux users know
> >|it. And although one can easily install bash on Solaris, it can't be
> >|used as a profile shell. I asked about this on blogs.sun.com and they
> >|said they would think about it..
> >|
> >|What do you think ? Would you consider including Bash as a standard
> >|Solaris shell a good thing (if not for yourself, to encourage Solaris
> >|adoption by users who use this shell) ?
> >
> >bash has been included in Solaris since Solaris 8. (Not that it helps
> >with the profile part.)
>
> I believe that it was a good idea to include bash. Making it the default shell
> is a bad idea as bash has a lot of nasty bugs.

"a lot" is likely an understatement. "More bugs than features" fits
better here... =:-)

Joerg Schilling

unread,

Jan 10, 2005, 8:12:47 AM1/10/05

to

In article <41E279CE...@nrubsig.org>,
Roland Mainz <roland...@nrubsig.org> wrote:

>Ugh. Current bash is a nightmare. No associative arrays, no i18n support
>beyond UTF-8 (well, there is bash3 - but that version isn't mature yet)
>and many other ksh/ksh93 goodies are missing.
>And bash is an ugly resource hog - it fetches nearly twice as much
>memory than the same shell sesssion under ksh93.

And in order to make bash /bin/sh, it would need to do jobcontrol
correctly. A Shell that does not disable jobcontrol when called
sh -c "command" is just broken and causes massive problems with
recursive make environment that look over directory lists.

Roland Mainz

unread,

Jan 10, 2005, 8:24:54 AM1/10/05

to

Joerg Schilling wrote:
>
> In article <41E279CE...@nrubsig.org>,
> Roland Mainz <roland...@nrubsig.org> wrote:
>
> >Ugh. Current bash is a nightmare. No associative arrays, no i18n support
> >beyond UTF-8 (well, there is bash3 - but that version isn't mature yet)
> >and many other ksh/ksh93 goodies are missing.
> >And bash is an ugly resource hog - it fetches nearly twice as much
> >memory than the same shell sesssion under ksh93.
>
> And in order to make bash /bin/sh, it would need to do jobcontrol
> correctly. A Shell that does not disable jobcontrol when called
> sh -c "command" is just broken and causes massive problems with
> recursive make environment that look over directory lists.

/bin/sh being bash in Solaris ? What a nightmare... horror... ;-(
I like the idea that /bin/sh is a small, lightwheight shell. Bourne
shell isn't likely being beatable at that point (compared to the bash
resource hog) ... :)
If /bin/sh needs to be replaced then ksh should be used instead.

Alan Coopersmith

unread,

Jan 10, 2005, 11:00:25 AM1/10/05

to

j...@cs.tu-berlin.de (Joerg Schilling) writes in comp.unix.solaris:

|In article <crs8co$g7f$1...@agate.berkeley.edu>,
|Alan Coopersmith <al...@alum.calberkeley.org> wrote:
|
|>There is no one Solaris build mechanism - it's built by combining
|>packages from different groups using the build mechanisms most
|>appropriate for them. For X & CDE, that's Imake-based, for GNOME,
|>that's GNU autotools, etc. The ksh portions of dtksh though use
|>the original, "unique" build mechanism that I believe came originally
|>from ksh88.
|
|If this is true, then things must have changed recently.

Nope, that's the way it's been as long as I have been working here -
which is almost 6 years now.

|About one year ago, I have been told that not a single FSF program
|is allowed to be part of the build environment for Solaris and that
|Sun needs to create a new build environment for my tools that are included
|with Solaris.

You must have been talking to one of the unfortunate people who confuse
"Solaris" with "the OS/Networking core of Solaris". The OS/Net (aka
ON, aka the bits used in the "Foundation Source" and initial OpenSolaris
releases) are crucial to Solaris, but some people forget there is far
more to Solaris than just it, and that the rest of Solaris works
differently. (And even for ON, there's some FSF software used to build
it for Solaris 10.)

unread,

Jan 11, 2005, 9:38:15 AM1/11/05

to

If they're going to do that, I would ask that they do the same thing
with zsh as well.

--
Coy Hile
hi...@cse.psu.edu

Brendan Gregg

unread,

Jan 11, 2005, 11:24:30 AM1/11/05

to

G'Day Roland,

On Mon, 10 Jan 2005, Roland Mainz wrote:

> Alan Coopersmith wrote:
[...]

> > |that it's less than two days of work. And there are at least two
> > |volunteers (including myself) who are willing to sign an NDA to do the
> > |job (if Sun is willing to ship the fix then with Solaris again). But

[...]

> > I doubt anyone's afraid of "free" work - if they were, OpenSolaris
> > wouldn't be happening. Unfortunately, CDE is not yet part of
> > the source released via OpenSolaris and I don't know if/when it will be.
> > (They're starting at the core, similar to what was previously released
> > as the "Foundation Source" program, and working their way out from
> > there.)
>
> I wasn't thinking about the OpenSolaris program here. I was thinking
> about signing an NDA, getting the damn source from Sun, fixing it and
> then submit the patch back for integration into Solaris 10 (for the log:
> It's dtksh in Solaris 10 which makes me worry, previous releases where
> not that bad except that they're based in sources more than a decade old
> (or something like that)).

Yes, please fix dtksh! Otherwise how else am I supposed to play xpong?, :)

http://www.brendangregg.com/dtkshdemos.html

Seriously, it would be great to see dtksh updated. (then my website may be
called dtkshtools rather than dtkshdemos!) In particular timed reads for
fractions of seconds (xplot - plot a field of any command; and xvmstat
need this ksh93 feature).

Brendan

[Sydney, Australia]

Roland Mainz

unread,

Jan 11, 2005, 4:49:10 PM1/11/05

to

Coy Hile wrote:
> > Right about that, my mistake.
> >
> > The only thing outstanding is bash as a Profile Shell for using with
> > RBAC.
>

> If they're going to do that, I would ask that they do the same thing
> with zsh as well.

ksh93 first, please (it's more or less a superset of bash anyway).

Roland Mainz

unread,

Jan 11, 2005, 4:54:17 PM1/11/05

to

Alan Coopersmith wrote:
>
> Roland Mainz <roland...@nrubsig.org> writes in comp.unix.solaris:
> |I wasn't thinking about the OpenSolaris program here. I was thinking
> |about signing an NDA, getting the damn source from Sun, fixing it and
> |then submit the patch back for integration into Solaris 10 (for the log:
>
> That's exactly what OpenSolaris is today. Sign an NDA, get source,
> change as desired, and either use it yourself,

It doesn't make much sense to ship dtksh binaries with Mozilla or our
own products so the integration of the fixes back into Solaris should be
the goal...

> or if you want to try to
> get it into Solaris, work with the Sun engineers assigned to OpenSolaris
> to do so.

OK... what's the exact procedure to get the NDA signed and back to Sun -
and who at Sun wants to volunteer to get dtksh back to live ?

Vlad Grama

unread,

Jan 12, 2005, 8:45:38 AM1/12/05

to

Actually, Stephen Hahn said in his answer to my blog comment that quite
a number of poeple in the kernel group are using ZSH so... maybe they
will add RBAC support for it.

Vlad.

Alan Coopersmith

unread,

Jan 12, 2005, 12:49:54 PM1/12/05

to

Roland Mainz <roland...@nrubsig.org> writes in comp.unix.solaris:

|OK... what's the exact procedure to get the NDA signed and back to Sun -

I'll ask the OpenSolaris coordinator.

|and who at Sun wants to volunteer to get dtksh back to live ?

I've seen too much of the dtksh build process to ever want to go back
there again. (Fortunately, I've forgotten most of it in the 5 years
since I last looked.)

Roland Mainz

unread,

Jan 12, 2005, 9:44:15 PM1/12/05

to

Alan Coopersmith wrote:
>
> Roland Mainz <roland...@nrubsig.org> writes in comp.unix.solaris:
> |OK... what's the exact procedure to get the NDA signed and back to Sun -
>
> I'll ask the OpenSolaris coordinator.

Thanks! :)

> |and who at Sun wants to volunteer to get dtksh back to live ?
>
> I've seen too much of the dtksh build process to ever want to go back
> there again.

Is the build process _that_ bad ?
I am starting to worry whether dtksh can be build "standalone", e.g.
without needing all the other CDE sources, too (well, having the rest of
the CDE codebase can't hurt[1]... :)

[1]=(as the next item on the list after dtksh is to get libDtPrint
implemented)

> (Fortunately, I've forgotten most of it in the 5 years
> since I last looked.)

heh.

David Combs

unread,

Jan 22, 2005, 3:21:31 PM1/22/05

to

In article <41E27BB8...@nrubsig.org>,

Roland Mainz <roland...@nrubsig.org> wrote:
>Joerg Schilling wrote:
>> >"Vlad Grama" <vgr...@gmail.com> writes in comp.unix.solaris:
>> >|A nice feature would be to have Bash integrated. All Linux users know
>> >|it. And although one can easily install bash on Solaris, it can't be
>> >|used as a profile shell. I asked about this on blogs.sun.com and they
>> >|said they would think about it..
>> >|
>> >|What do you think ? Would you consider including Bash as a standard
>> >|Solaris shell a good thing (if not for yourself, to encourage Solaris
>> >|adoption by users who use this shell) ?
>> >
>> >bash has been included in Solaris since Solaris 8. (Not that it helps
>> >with the profile part.)
>>
>> I believe that it was a good idea to include bash. Making it the default shell
>> is a bad idea as bash has a lot of nasty bugs.
>
>"a lot" is likely an understatement. "More bugs than features" fits
>better here... =:-)
>

>Roland

Question: is that bash in general, or just sun's?

David

McBofh

unread,

Jan 22, 2005, 4:32:35 PM1/22/05

to David Combs

David Combs wrote:
> In article <41E27BB8...@nrubsig.org>,
> Roland Mainz <roland...@nrubsig.org> wrote:

...

>>>I believe that it was a good idea to include bash. Making it the default shell
>>>is a bad idea as bash has a lot of nasty bugs.
>>"a lot" is likely an understatement. "More bugs than features" fits
>>better here... =:-)
>>Roland
> Question: is that bash in general, or just sun's?

No, it's bash in general. Sun merely compiles it, runs
their standard test suite over it and ships it.

bash is buggy and it doesn't matter which vendor you
get it from (including gnu.org).

mcbofh

Roland Mainz

unread,

Jan 22, 2005, 8:56:20 PM1/22/05

to

David Combs wrote:
> >> >"Vlad Grama" <vgr...@gmail.com> writes in comp.unix.solaris:
> >> >|A nice feature would be to have Bash integrated. All Linux users know
> >> >|it. And although one can easily install bash on Solaris, it can't be
> >> >|used as a profile shell. I asked about this on blogs.sun.com and they
> >> >|said they would think about it..
> >> >|
> >> >|What do you think ? Would you consider including Bash as a standard
> >> >|Solaris shell a good thing (if not for yourself, to encourage Solaris
> >> >|adoption by users who use this shell) ?
> >> >
> >> >bash has been included in Solaris since Solaris 8. (Not that it helps
> >> >with the profile part.)
> >>
> >> I believe that it was a good idea to include bash. Making it the default shell
> >> is a bad idea as bash has a lot of nasty bugs.
> >
> >"a lot" is likely an understatement. "More bugs than features" fits
> >better here... =:-)
> >
> >Roland
>
> Question: is that bash in general, or just sun's?

It's bash in general (and if you are using it in an locale outside
ISO-8859-1/-15 or C then you'll start to hate it even more as it's i18n
support is limited to single-byte locales and UTF-8 (bash3 is slightly
better but still fails to do anything usefull in locales like ja_JP.PCK
etc... ;-()).

Roland Mainz

unread,

Jan 22, 2005, 8:57:06 PM1/22/05

to

Roland Mainz wrote:
> > Roland Mainz <roland...@nrubsig.org> writes in comp.unix.solaris:
> > |OK... what's the exact procedure to get the NDA signed and back to Sun -
> >
> > I'll ask the OpenSolaris coordinator.
>
> Thanks! :)

Any news yet ?

Alan Coopersmith

unread,

Jan 23, 2005, 1:04:28 PM1/23/05

to

No, but he's a bit busy getting ready for the events of this coming
week. I'll ping him again once that's past.