Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

A Real Bourne Shell for Linux?

Cliff posted more than 12 years ago | from the is-bash-really-all-that-different dept.

Linux 388

the_code_poet asks: "I'm a lead developer for a software development company, and one of my responsibilities has been writing an installer for our product (of which Linux is one of the platforms). In keeping with UNIX tradition, the installer is written in shell (thats /bin/sh), but as many of you know there is no Bourne shell for Linux - only bash. This has caused inconsistencies (mostly bugs in bash) when writing a generic UNIX sh script that works fine on commerical *NIX's." For a semi-complete list of differences between bash and sh, you will want to check out section C1 of the Bourne Again Shell FAQ. To be honest, I have yet to run into much trouble with a script starting with #!/bin/sh with /bin/bash, and I've been using the latter for years. If any of you have had problems related to this, please tell us what the problem was and how you solved it. Also: would anyone out there be interested in writing a real Bourne Shell for Linux?

"On every distro I've ever seen /bin/sh is just a soft link to /bin/bash. If bash is invoked with sh as its name (argv[0]) then its supposed to act like Bourne - but that just doesnt happen (for example: export FOO=bar is *not* valid Bourne shell syntax, you must say FOO=bar; export FOO)

Do you think that the startup scripts for most distributions would break because, even though they say
#!/bin/sh at the top, they REALLY mean #!/bin/bash?

Given that there is no real Bourne shell for Linux, and that bash has an exhorbitant file size. Quoting bash's man page, here: '...it's too big and too slow' for something that is to be used as the defacto-standard shell for scripting, do you think its a worthy venture to set out to write a small, tight, pure Bourne shell?

*asbestos disclaimer*: This has nothing to with Bash as an interactive user shell and has nothing to do with a holy war over who's favorite shell is better than whomever's."

While doing a small bit of research on this question, I noted there was another Bourn-compatible shell out there called "ash", yet it's billed as doing "some things better and some things worse than bash". Does anyone use it, and find it better than bash for their shell scripting needs?

cancel ×

388 comments

Sorry! There are no comments related to the filter you selected.

How linux is still an inferior desktop OS (-1)

Anonymous Pancake (458864) | more than 12 years ago | (#2579668)

How linux is still an inferior desktop OS

Hello, as an experienced MCSE, I have worked with many systems before for different corporations, and although I find linux to be a suitable server OS, there are many problems that have to be addressed before it will be able to compete with windows in the desktop world. Here are some suggestions I have come up with that will help linux become more competitive.

1) Remove the bloat. Most linux distro's ship with way to many useless programs. Desktop users do not need 10 different text editors. Give them one or two good ones and that will be enough.

2) Dump the command line. Desktop users do not use command lines. Windows is light-years ahead in this regard. Even their server OS has a great gui, and it is not necessary to use the command line. Linux needs to follow Microsoft's lead and get rid of the command line. You could maybe include an option for advanced users, like how windowsXP has an ms-dos prompt, if you really want to use it.

3) Dump open-source. Normal desktop users do not care about source code, they care about good programs. They do not want to compile anything. Linux needs real companies that actually know how to make good interfaces. Right now they are few and far between.

4) A universal gui system. Linux needs ONE gui. Perhaps people should focus on developing KDE into a competitive platform. Forget about gnome and everything else.

5) Make upgrading the software easier. Desktop users need an easy way to upgrade the kernel.

6) Get a good web browser. Linux has no good web browsers right now. Netscape is old and bloated. Opera cost extra and lacks some features. Mozilla is still beta and isn't even up to version 1.0 yet, so it doesn't count. Linux needs a browser that is competitive with IE, and right now IE is light-years ahead of anything for linux.

7) Proper office programs. If you want Linux to be used in offices, you need decent applications. These programs should be able to import all MS formats, past and present. Microsoft is still light years ahead when it comes to their office programs.

8) Backward compatibility. WindowsXP can run dos programs, windows 3.11 programs, windows9x programs, windowsNT programs, ect... Linux is barely backward compatible.

Right now I would recommend windowsXP for any sensible desktop user. Linux is still too complicated and fragmented to appeal to the typical user. Perhaps in a few years time they will be on par with windows, and a few people may try it.

Re:How linux is still an inferior desktop OS (0, Offtopic)

HP-UX'er (211124) | more than 12 years ago | (#2579677)

gnome is definitly going on the rise, with more and more *NIX's making it their default GUI in next releases ...

Re:How linux is still an inferior desktop OS (-1, Troll)

Anonymous Coward | more than 12 years ago | (#2579705)

STANDARDIZED TROLL REPLY FORM
(original by Spootnik)

I took exception to your recent _X_ comment to __slashdot______

___ story

It was (check all that apply):

___ first post.
___ ascii art.
_X_ karma whore.
___ modded on crack.
___ counter lameness filter.
___ racist.
___ raging homosexual.
_X_ much longer than any worthwhile thought of which you may be capable.

Your attention is drawn to the fact that:

_X_ what you posted/said has been done before.
(Mark only if above checked)
_X_ Not only that, it was also done better the last time.
___ your post/letter was a pathetic imitation of ____________________.
(net.personality)
___ your post/mail originated on AOL.
___ your post/mail originated from the anon service
___ your post/mail originated from a commercial service unwise enough to
take your money
(Mark only if above checked)
___ you felt this gave you a license to be a 'tard
(Mark only if above checked)
___ your stupidity will be reported to jamie@mccarthy.vg per
the crackhead disclaimer under "excessive bad posting"
_X_ your post referred to the slashdot as a reliable source of information.

___ you posted a boring anecdote about your nerdy behaviours.
___ you posted a request for sexual favor.
___ you posted a pointer to goatse.cx
___ you asked for dirty pictures.
___ you posted a personal ad to a personal web site
___ you posted a request for a Beowulf cluster of that.
___ you posted a request for Nathalie Portman
___ Naked and petrified.
___ you poored hot grits down your pants.
___ you are not wearing pants.

___ your post contained numerous spelling errors.
___ including the subject line
_X_ your post contained multiple grammatical errors.
___ YOUR POST CONTAINED EXCESSIVE CAPITALIZATION AND/OR PUNCTUATION!!!!!
___ you posted a spelling and/or grammar flame.
(Mark only if above checked)
___ and you made spelling and/or grammatical errors.
_X_ you have a lame login name.
___ you quoted an article in followup and added no new text.
___ you quoted an article in followup and only added ___ lines of text.
___ you posted an identical article multiple times.
___ you apologized claiming a problem with your brain.
___ you followed up a spam or a chain letter and included it in its entirety.
___ you quoted an article in followup and only added the line "Me, too!!!"
___ you predicted the "Imminent Death of BSD".
___ you flamed someone who has mentionned the word "Microsoft".
_X_ you filthy hippy bragged about the all mighty Linux.
_X_ you failed to read the article.
___ your .sig is longer than four lines.
(Mark only if above checked)
___ And the lameness filter truncated it.
___ your .sig is ridiculous because (check all that apply):
___ you listed ___ email addresses for trolls to use in prank posts.
___ you included a stupid disclaimer.
(Mark only if above also)
___ your pathetic attempt at being witty in the disclaimer failed.
(Mark only if above also)
___ Miserably.
___ you included:
(Mark all that apply)
___ a stupid self-quote.
___ a stupid quote from 1st amendment.
___ a Star Trek quote.
___ a lameass joke.
___ a reference to Osama Bin Laden.

Furthermore:

___ You have greatly misunderstood the purpose of ________________________.
___ You have greatly misunderstood the purpose of masturbating.
_X_ You are a loser.
___ You must have spent your entire life in a skinner box to be this clueless.
___ *plonk*
___ This has been pointed out to you before.
___ Propz to all my dead homiez.

_X_ It is recommended that you:
(Mark all that apply)
___ stick to Adequacy and come back when you've grown up.
___ find a volcano and throw yourself in.
___ get a gun and shoot yourself.
___ stop reading Salshdot news and get a life.
_X_ stop posting comments and get a life.
___ consume excrement.
___ consume excrement and thus expire.

Additional comments:

None needed.

(C) Copyright 2001 - Anonymous Coward (-1, Troll)

Anonymous Coward | more than 12 years ago | (#2579849)

I forgot to mention no logged in luser can use this troll, it's for AC's only.

Re:How linux is still an inferior desktop OS (1, Insightful)

Anonymous Coward | more than 12 years ago | (#2579801)

except on the *NIX that is growing the fastest, Linux, KDE is still include as default in every major distrobution except for RedHat. It is also default in the second largest *NIX, FreeBSD.

Face it, gnome is dead. all of the gnome developers should switch to KDE or else their work will be at loss.

Re:How linux is still an inferior desktop OS (0)

Anonymous Coward | more than 12 years ago | (#2579720)

  1. You could maybe include an option for advanced users, like how windowsXP has an ms-dos prompt, if you really want to use it.

Are you kidding? Bash is light-year ahead of the ms-dos prompt.

YHBFTA (-1, Flamebait)

Anonymous Coward | more than 12 years ago | (#2579856)

you have been fucking trolled, asshole!

Not "sh" for Linux... (0, Troll)

Jetson (176002) | more than 12 years ago | (#2579682)

I'd rather see bash on HP/UX, etc. Why should we take a giant leap backward for their sake?

Re:Not "sh" for Linux... (1)

conway (536486) | more than 12 years ago | (#2579691)

You can easily compile and install bash on HP-UX.
(I've done it in under 2 minutes.)
Also, there are people committed to distribution of most popular GNU tools in binary for HP-UX and other commercial *NIXes, even though most compile and install from source without problems.
(with the notable exception of gcc of course. Sheeesh -- try and get THAT to compile cleanly!)

Re:Not "sh" for Linux... (2)

dangermouse (2242) | more than 12 years ago | (#2579717)

There are a lot of Bourne-compatible shells that aren't bash-compatible. So sometimes it makes sense to develop for Bourne, if you have to do shell scripting.

On the other hand, sometimes you just don't care, and you can make full use of bash or ksh or whatever.

Re:Not "sh" for Linux... (-1)

Anonymous Coward | more than 12 years ago | (#2579791)

I wouldn't. I'm not infecting my HP boxes with the GPV.

Besides, what's wrong with running scripts with sh? 99% of all scripts I see calling bashing would run just fine with sh.

Newer does not mean better.

To top it all off, sh requires less memory; oh, and if you want to say "memory is cheap", why don't you just install win XP?

oh my gosh (0)

kentyman23 (466366) | more than 12 years ago | (#2579833)

To top it all off, sh requires less memory; oh, and if you want to say "memory is cheap", why don't you just install win XP?

that's the dumbest thing i've ever heard... this compare the memory usage of WinXP and bash is rediculous...

bash on HP-UX (0)

kentyman23 (466366) | more than 12 years ago | (#2579844)

http://hpux.connect.org.uk/hppd/hpux/Shells/bash-2 .05/

i use it everyday at work. i suggest looking around for things you want rather than just asking for them.

Easy. (5, Informative)

Flarners (458839) | more than 12 years ago | (#2579683)

  1. Download FreeBSD source.
  2. cd /usr/src/bin/sh; make; make install
AFAIK the BSD Bourne shell is more or less the same as the real Bourne shell.

Re:Easy. (1, Insightful)

Vanbo (75942) | more than 12 years ago | (#2579765)

Why has this been marked down to -1?

He just gave a valid solution.

Include the FreeBSD source to /bin/sh with your product, have a simple script compile and install it on the Linux both someplace. Have your complicated install script use the new bourne shell for installing your app.

I am hoping it was just accidentally marked down with the thought: "Oh no, someone is telling him to install FreeBSD, better mark it down"

This is not what the parent was suggesting. Read carefully before blindly modding down based on seeing something you don't like...

Re:Easy. (-1)

Klerck (213193) | more than 12 years ago | (#2579775)

Congratulations! You've encountered a "bitchslapped" user. When the editors don't like a certain account, they bitchslap it to auto-post at -1. Your beloved editors are censors themselves!

What vacuum are you living in? (ksh and zsh) (-1, Flamebait)

aheitner (3273) | more than 12 years ago | (#2579685)

I won't be the first to say this, but oh well.

"WHAT CAVE DID YOU JUST CRAWL OUT OF?!"

Ok. ksh and zsh are supersets of the POSIX shell. And I agree, strictly speaking it's bad to shebang /bin/sh and then commit travesties like "export FOO=bar".

But give me a break.

If you want to script, you have no excuse to be using anything other than ksh (or just maybe ash).

AIX comes with only ksh in the way of POSIX-shells.

Why do we have to live like there has been zero progress since the original POSIX shell spec? And who could be so brain-damaged as not to notice ksh, the unquestioned pinnacle of scripting shells, and zsh, the unquestioned epitome of user shells?

Gee whiz. Don't waste your time; go write something useful.

(....grumble, grumble, idiotic duplication of effort....)

Did you even read the complaint? (4, Interesting)

Wakko Warner (324) | more than 12 years ago | (#2579715)

The guy writes installer scripts for a living. Every other unix has a Bourne shell implementation except Linux, and Linux's /bin/bash has incompatibilities. Telling the guy to fuck off and use something else has got to be the most ignorant thing I've ever heard. I'm sure he can tell his boss the same thing, right? "Fuck this, I'm gonna use ksh so it works on... AIX only!"

Ask Slashdot becomes less helpful by the nanosecond.

- A.P.

Re:Did you even read the complaint? (1)

anfloga (139529) | more than 12 years ago | (#2579750)

Hear hear, some of these posts, MODDED UP (don't ask my why) are telling this guy that bash is backward compatible to sh, when it shows an example RIGHT IN THE STORY HEADER of how this isn't so (an incompatibility that I've run into myself, actually). Luckily, I use "question exchange", NOT ask slashdot, if I have a hard question I can't answer, because my question goes to the right people (not every lifeless "I think I know everything" on the face of the planet) and gets answered correctly more than half the time. Usually with insights and angles I didn't even consider.

Erik

Re:Did you even read the complaint? (1)

J4 (449) | more than 12 years ago | (#2579809)

Luckily, I use "question exchange", NOT ask slashdot,

QuestionExchange Close Down
From: hgonzalez@questionexchange.com
To: ts-xxxxxx@xxxxxx.net

Dear John (xxxxxx),

Due to the changing economic climate, and change of focus within VA Linux,
QuestionExchange.com will be closing at the end of July. We thank you
for your support and participation over the last couple of years and regret
this necessary step.

Should you have any question please contact us at: info@questionexchange.com.

Regards,

Hector Gonzalez
Director - QuestionExchange

QE wasn't bad, for a scam.

Question exchange? (OT) (2)

vrt3 (62368) | more than 12 years ago | (#2579818)

When was the last time you used question exchange? (I presume you mean http://www.questionexchange.com [questionexchange.com] ?). I'm asking you since I got an email from them back in July, stating that QuestionExchange was closing down (no doubt as a result of certain [slashdot.org] events [slashdot.org] at VA Linux).

I even submitted a story about it, but it was rejected:

  • 2001-07-30 19:57:03 QuestionExchange Closed Down (articles,news) (rejected)

Re:Did you even read the complaint? (1)

psamuels (64397) | more than 12 years ago | (#2579853)

when it shows an example RIGHT IN THE STORY HEADER of how this isn't so (an incompatibility that I've run into myself, actually).

What example would that be? All I saw was a vague statement to the effect that "bash has had weird bugs in the past". Doubtless it is true, but what is one supposed to do about that? All programs have had weird bugs in the past - you just have to tell your customers that your install script may not work if they're still using really old versions of bash -- just like you tell them that your software no longer works on HP-UX 8 or 9.

To be clear, the syntax 'FOO=BAR; export FOO' works just fine on bash, so that can't be the "example right in the story header" you mentioned.

Using ksh extensions to POSIX is just as bad as using bash extensions to POSIX - if a vendor script uses ksh-isms it may well work on all commercial Unices and not on Linux. But in that case I consider it the vendor's own problem.

Re:Did you even read the complaint? (4, Insightful)

aheitner (3273) | more than 12 years ago | (#2579795)

Yes. I did.

And it was nonsensical.

If he's going to complain about bash being not exactly POSIX, he's got to show an example of an incompatibility (as a decent sometime bash and ksh hacker, I can't think of one -- and I can think of one subtlety that ksh and zsh do differently than POSIX: word splitting).

Ok. "export FOO=bar" doesn't work on a strictly-POSIX shell. But why is it bad for that to work in bash (and ksh and zsh)? How does that hurt you?

Instead, why doesn't the article's poster come up with an example of a valid POSIX statement that breaks in bash -- that way he actually has a complaint: he did something POSIX (i.e., the standard), and bash did the wrong thing. As it stands, he's just griping.

I mean, I agree with him -- bash is bloated and not a good choice for scripting. But that just means that scripts should be written in a shell optimized for scripting -- ksh. Or at least a minimalist straightforward POSIX shell (ash).

But if a system wants to provide just one POSIX shell (to save space, or whatever), and if bash is going to be used by 95% of users anyhow (so is likely to be loaded anyhow), making the one POSIX shell available on the system be bash isn't a bad call. Now that doesn't excuse scripts using non-POSIX features under the name of /bin/sh. But I'd hazard to guess that 99% of the time those scripts are distro-specific in many other ways, so it doesn't really matter.

I still have yet to see how (from anything but an efficiency perspective), this guy is finding that bash somehow makes his life harder.

(side-point: it is annoying that you can't solve the efficiency problem by relinking /bin/sh to ksh or ash, since all the system scripts will do slightly-non-POSIX things and therefore should be specifying /bin/bash).

...

I apologize for my confrontational tone. It really irks me when people propose writing things without bothering to check if the work has been done for them. I mean, come on, guys, it's Free Software. Avoiding duplication is the name of the game.

Re:Did you even read the complaint? (1)

psamuels (64397) | more than 12 years ago | (#2579832)

Instead, why doesn't the article's poster come up with an example of a valid POSIX statement that breaks in bash

typeset -u varname

I don't know if it's strictly POSIX, but ksh supports this syntax for constraining a variable to auto-convert its contents to uppercase whenever you set it. This is the reason I can't use bash for my root shell in AIX - some poorly-written scripts don't have #! lines and rely on 'typeset -u'.

Re:Did you even read the complaint? (2)

larien (5608) | more than 12 years ago | (#2579815)

ksh is available on stock IRIX, AIX, Solaris and HP-UX. Even linux/FreeBSD can now have it for free after some fairly recent license loosening.

On the other hand, bash is standard on linux, FreeBSD and Solaris 8 (maybe even AIX 5L? haven't seen that yet). Hrm, let me see which is more widespread? :)

Personally I prefer zsh for interactive stuff and it's as good as bash/ksh for most scripting stuff. I say most, because otherwise someone will come back with some whiz-bang feature of bash/ksh to prove a point. Most of my scripting works fine in sh; that's the stock sh that comes with most versions of Unix, but then I don't do very much fancy stuff.

Re:What vacuum are you living in? (ksh and zsh) (0)

Anonymous Coward | more than 12 years ago | (#2579733)

commit travesties like "export FOO=bar"

Why is that a travesty? It's clear - clearer than "FOO=bar; export FOO" - and logical.

The fucking bourne shell should be updated to match it... never mind dragging everyone else down to its level of mediocrity.

Re:What vacuum are you living in? (ksh and zsh) (1)

anothy (83176) | more than 12 years ago | (#2579734)

i'm almost afraid if i comment here your head'll explode...
...ksh, the unquestioned pinnacle of scripting shells...
unquestioned, huh? go tell that to the bash guys. or the ash guys. or, heck, me. ksh is pretty good, but it's certainly not the unquestioned anything, and i'd question whether it's the best scripting shell available (even using a narrow definition of shells that exclude things like perl).
...zsh, the unquestioned epitome of user shells?
again, tell that to the bash folks, or the dozens of other user shells out there. personally, i love rc, for both scripting and interactive use. doesn't have all the features of the others, but is much less complex, much smaller, and simpler and more consistent to use. but the point is that there's no unquestioned shell for anything.
not to mention the fact that your "suggestion" totally ignore the guys problem: writing a cross-platform install script. zsh is totally non-standard, so that's out. ksh is pretty common, but not totally common, and is installed as different things in different places. there's definatly a place for a standard (you linux guys remember those, don't you?), and, for the time being, bourne shell's it. so either linux gets with the standard program, or it continues to be a pain.

(Sorry, a little clarification) (3, Insightful)

aheitner (3273) | more than 12 years ago | (#2579828)

I apologize if my tone comes off confrontatively :-).

I'm reacting negatively to the idiotic suggestion that people need to waste time "writing a real Bourne shell for Linux".

If you don't like bash, there are several other shells which attempt to be POSIX. Some of them are quite strict (ash). Some are optimized for scripting (ksh).

If you want to argue that bash sucks and should be replaced as the default system scripting shell, I totally agree. If you want to say that it sucks when scripts request /bin/sh but use bash-specific features, I agree.

But for goodness sake, give some respect to the work that's been done.

...

I did see one good post noting the bash specifics that are missing, as a POSIX shell. They really are quite minor...

2nd hit on Google (0, Informative)

VA Software (533136) | more than 12 years ago | (#2579687)

Re:2nd hit on Google (2)

pete-classic (75983) | more than 12 years ago | (#2579727)

How is that helpful? It suggests "download[ing] the real thing and use[ing] that" with no link or even indication of where to get the real thing.

I was excited when I saw this story, and again when I saw your post, because I had the same question in the past and was never able to find a satisfactory answer.

Still haven't.

-Peter

Re:2nd hit on Google (1)

VA Software (533136) | more than 12 years ago | (#2579738)

It suggests

Ksh93 may be had, precompiled for Linux, via www.kornshell.com

Which another poster in the thread has said works.

Also, it shows that lots and lots of people have asked the same question already - and got similar answers to the answers posted here. Doing a bit of research is quicker than submitting an ask /.

Re:2nd hit on Google (2, Informative)

Vanbo (75942) | more than 12 years ago | (#2579821)

Ok guess its never going to get modded up because it has FreeBSD in it...

Here is the source to what is very close to "the real thing"

ftp://ftp.freebsd.org/pub/FreeBSD/branches/4.0-s ta ble/src/bin/sh/

So the answer is still, "Use the real bourne sh" and here is how you do it. Download, compile (on linux) and install to some place that won't effect linux. Have your install script call the newly made "real" shell.

Wasn't hard eh?

Why Use Google? (-1)

egg troll (515396) | more than 12 years ago | (#2579779)

When you can just Ask Slashdot, and have dozen's of know-it-all Slashbots get the answer for you!

/bin/bash (3)

Z4rd0Z (211373) | more than 12 years ago | (#2579689)

Starting your scripts with #!/bin/bash shows that you live in a Linux-centric world. No other OS puts bash under /bin. Since there's normally a link from bash to sh, it really makes sense for compatibility reasons to use #!/bin/sh. Of course, if you use bash-specific features in your scripts, your scripts won't be portable anyway and it doesn't really matter, I suppose.

Re:/bin/bash - It all sounds so brutal (3, Funny)

Anonymous Coward | more than 12 years ago | (#2579707)

hash bang slash bin slash bash

Re:/bin/bash - It all sounds so brutal (1)

TicTacTux (99149) | more than 12 years ago | (#2579793)

...been to thinkgeek lately?

Use the source, Luke!

Re:/bin/bash (0)

Anonymous Coward | more than 12 years ago | (#2579737)

If a script really wants bash it should call bash. Period. No exceptions. It should not assume just because a user is running linux that sh will be bash.

No other OS? (1)

Doktor Memory (237313) | more than 12 years ago | (#2579787)

No other OS puts bash under /bin.

Except for Solaris 2.7 and 2.8. Ahem.

Re:No other OS? (1)

larien (5608) | more than 12 years ago | (#2579798)

Ahem indeed:
  1. There is no such thing as Solaris 2.8, and 2.7 only exists in some places. I assume you meant 7 and 8.
  2. bash was only introduced into Solaris as of Solaris 8 along with zsh, apache, gzip and some other GPL stuff.
  3. /bin is actually a symlink to /usr/bin, so technically it doesn't put it under /bin
Oops, better put on the asbestos now :)

Re:No other OS? (3, Interesting)

green pizza (159161) | more than 12 years ago | (#2579848)

1. There is no such thing as Solaris 2.8, and 2.7 only exists in some places. I assume you meant 7 and 8.

Bah, "Solaris" is the marketing name. It's SunOS 5.8. Do a 'uname -a' if you don't belive me. Besides, it fits perfectly with SunOS history... versions prior to 5.0 were BSD based, version 5.0 and newer are heavily SysV based. The whole "Solaris" name just confused everyone.

Re:/bin/bash (1)

Ninja_Gaiden_III_cut (536454) | more than 12 years ago | (#2579812)

None has to berate Linux, the kernel and sources were done by programmers in the reason of they had to do an exciting and cool thing.
We have to get motivation and we have to do a new thing: Bourne shell for Linux.

- The power is ours, the money is with MS.

Re:/bin/bash (2)

seebs (15766) | more than 12 years ago | (#2579839)

BSD/OS ships with bash in /bin.

And yes, I have been burned regularly by scripts which assumed that "sh" would have bash extensions.

Try this out! (1, Informative)

KGB Kenny (238697) | more than 12 years ago | (#2579690)

Why couldn't you just write a small script that chooses what shell to use at the beginning?

Say the following:

File 1: Shell script to determine what *nix you are running

File 2: Bourne shell script

File 3: bash shell script

File 1 determines whether to use Bourne shell script of bash shel script and passes it onto decided shell.

Just a thought... hope I could be helpful!

-theKGB 8)

Re:Try this out! (2, Insightful)

anothy (83176) | more than 12 years ago | (#2579740)

problems here:
first, what's the first script to be written in, that it'll run on any unix? i guess this is easier than the general case, but still not an issue to ignore.
also, this more than duplicates the work of writing and maintaining these scripts. you've got the install scripts twice, plus the selector script.

use ash (0, Redundant)

|_az (87) | more than 12 years ago | (#2579693)

~% apt-cache show ash
Package: ash
Priority: optional
Section: shells
Installed-Size: 180
Maintainer: Herbert Xu <herbert@debian.org>
Architecture: i386
Version: 0.3.8-29
Pre-Depends: libc6 (>= 2.2.4-2)
Filename: pool/main/a/ash/ash_0.3.8-29_i386.deb
Size: 70564
MD5sum: a9ec33985be6e3a4c350ef19d377c43a
Description: NetBSD /bin/sh
"ash" is a POSIX compliant shell that is much smaller than "bash".
We take advantage of that by making it the shell on the installation
root floppy, where space is at a premium.
.
It can be usefully installed as /bin/sh (because it executes scripts
somewhat faster than "bash"), or as the default shell either of root
or of a second user with a userid of 0 (because it depends on fewer
libraries, and is therefore less likely to be affected by an upgrade
problem or a disk failure). It is also useful for checking that a
script uses only POSIX syntax.
.
"bash" is a better shell for most users, since it has some nice
features absent from "ash", and is a required part of the system.

House (-1)

Guns n' Roses Troll (207208) | more than 12 years ago | (#2579694)

Can someone reccomend some good vocal house music? Something along the lines of Full Intention feat. Shena - I'll Be Waiting and Kings Of Tomorrow feat. Julie McKnight - Finally.

It's a non-issue. (5, Interesting)

mindstrm (20013) | more than 12 years ago | (#2579698)

You are looking for a solution to a problem that does not exist.

bash is backward compatable to sh. Period.

Yes, you can do things in bash you can't do in sh, but not vice-versa.

If you write your scripts for stock Bourne, they will run fine under bash.

Re:It's a non-issue. (2, Insightful)

// (81289) | more than 12 years ago | (#2579713)

It's not *quite* a non-issue.

If you want to use sh, start with #!/bin/sh rather than #!/bin/bash - the executable notes which name you invoke it with and adjusts a couple of minor details of behaviour accordingly.

Re:It's a non-issue. (2)

mindstrm (20013) | more than 12 years ago | (#2579725)

yes.. and there are a few other, very minor differences, well documented in the bash documentation, which any devleoper could very easily account for.

Re:It's a non-issue. (5, Informative)

pete-classic (75983) | more than 12 years ago | (#2579781)

What you are saying is valid, but it misses the point.

Even if every valid bourne script runs perfectly under bash there is still a problem.

That problem is that an interpreter enforces valid syntax. It would be nice if everyone who wanted to write a portable (read bourne) script spent a month studying and was totally zen-ed out on the subject. But that 'aint the real world.

I personally could benefit from a real sh on Linux, since it is the only *NIX I have, and I can't test scripts for sh compatibility without it.

To be more specific, I wrote a bash script that was included in an OSS project. The maintainer wanted me to change the first line from "#!/bin/bash" to "#!/bin/sh" "for compatibility." I told him that I wasn't comfortable with this since the script wasn't tested on sh. He said he tested it and it worked fine. I asked him if he really tested it with sh or with "/bin/sh -> /bin/bash". Turned out it was the latter. Apparently he made the change anyway.

A while later we got a bug report on the list to the effect "your script is not a valid sh script." Luckily the guy sent a diff, and I tested it with bash. I guess it works with sh now too, but I still don't know for sure.

See how it isn't a non-issue, at least for me?

-Peter

Re:It's a non-issue. (5, Insightful)

seebs (15766) | more than 12 years ago | (#2579845)

Embrace and extend. There is no way to write a script in bash and have bash warn you if you're using an extension, so they tend to creep into scripts. Embrace and extend is evil; the compatability mode should be *pure* sh, with no extensions.

why not... (0)

Anonymous Coward | more than 12 years ago | (#2579700)

... make? make install? some other shell that doesnt have such ambiguity? like csh? or tcsh?

Re:why not... (0)

Anonymous Coward | more than 12 years ago | (#2579723)

As the guy said, they did all of their development for sh without thinking, and now that they realize it was a bad choice, the lead developper is begging slashdot for a quick way out to avoid getting fired.

Slackware uses ash for toolset (5, Informative)

dangermouse (2242) | more than 12 years ago | (#2579708)

Slackware uses ash because (a) it's tiny and (b) it's restrictively Bourne-compatible, which means you won't write some tool that is accidentally dependant on bash.

Basically, Slackware uses ash for development for the exact reasons you're looking for a Bourne-compatible shell.

Have fun.

Re:Slackware uses ash for toolset (0)

Anonymous Coward | more than 12 years ago | (#2579756)

Yeah, but Slackware is crap and on its last legs. So who cares?

Re:Slackware uses ash for toolset (1)

TicTacTux (99149) | more than 12 years ago | (#2579786)

If that is your personal opinion please declare it as such. Just because you haven't been able to get beyond YaST or linuxconf this doesn't mean all the rest is crap. Sure, Slackware is neither for the faint of heart nor for the illiterates...

Use the source, Luke!

Re:Slackware uses ash for toolset (0)

Anonymous Coward | more than 12 years ago | (#2579837)

Its for the people who think their l33t by using something non-standard.

Re:Slackware uses ash for toolset (1)

TicTacTux (99149) | more than 12 years ago | (#2579843)

And what, if I might ask, is the standard?

Re:Slackware uses ash for toolset (1)

ethereal (13958) | more than 12 years ago | (#2579776)

Almost all installation boot disks seem to use ash, for pretty much the same reasons. I'm writing an installer right now an am using ash, in fact. For simple shell scripting, the extra size of bash just isn't worth it.

Bourne, Smourne (-1, Troll)

Anonymous Coward | more than 12 years ago | (#2579709)

Who cares? Linux is dead anyway.

Why is Linux dead? (-1)

jfonseca (203760) | more than 12 years ago | (#2579854)

I've been reading so many comments in that sense, why is Linux dead? I don't see it dead. Lately I had to write a solution to this problem at day job, and no Windows 2000 machine did it, but my pentium 200 frankenstein with Perl did it in seconds....

200 day uptime, only down 200 days ago to upgrade kernel and it's about time I do it again, now why is Linux dead?

bash as /bin/sh (4, Informative)

zdzichu (100333) | more than 12 years ago | (#2579710)

"On every distro I've ever seen /bin/sh is just a soft link to /bin/bash."
You haven't seen Polished Linux Distribution [pld.org.pl] . PLD's /bin/sh is not bash, and all 'bashisms' are removed from distribution's scripts - it's all plain /bin/sh.

(Plus, PLD is fully IPV6 ready :)

Bourne shell or POSIX shell? (5, Informative)

psamuels (64397) | more than 12 years ago | (#2579711)

Do you think that the startup scripts for most distributions would break because, even though they say #!/bin/sh at the top, they REALLY mean #!/bin/bash?

Many would. However, note that POSIX requires /bin/sh to be a POSIX shell, whose specs are derived mostly from the Korn Shell - so ksh is a valid POSIX shell, as is Bash, modulo a few features. Plain-vanilla Bourne shell is not.

AIX has the same dilemma: to be POSIX-compliant they have /bin/sh -> ksh and /bin/bsh is the real Bourne. HP-UX 11 has /bin/sh distinct from ksh, but it too allows things like 'export FOO=BAR'. I don't know if a real Bourne shell exists on HP-UX.

For a POSIX shell without the bash overhead, use ash, which is distributed with many (most?) Linux distributions. ash is the NetBSD /bin/sh, and at least on Debian the installation gives you the /bin/sh symlink option as well. Let me tell you, ash is much faster than bash in the autoconf-generated-configure "benchmark".

Since many Debian people use ash for /bin/sh, packages regularly have bugs filed -- and fixed -- vis-a-vis #!/bin/sh vs. #!/bin/bash. I don't know how careful other distros are about this sort of thing. Note that even many Debian scripts would fail if you found a real Bourne shell for /bin/sh rather than a POSIX-compliant shell.

Stolen microsoft infoz (0)

Anonymous Coward | more than 12 years ago | (#2579714)

Do with it what you will.
--Anonymous Coward

Microsoft Authorization Data Specification v. 1.0 for Microsoft Windows 2000 Operating Systems
April, 2000

Abstract

Microsoft Windows 2000 includes OS specific data in the Kerberos V5 authorization data field that is used for authorization as described in the Kerberos revisions Internet Draft [1]. This data is used for user logon and to create an access token. The access token is used by the system to enforce access checking when attempting to reference objects. This document describes the structure of the Windows 2000 specific authorization data that is carried in that field.

Top-Level PAC Structure

The PAC is generated by the KDC under the following conditions:
"during an AS request that has been validated with pre-authentication
"during a TGS request when the client has no PAC and the target is a service in the domain or a ticket granting service (referral ticket).

The PAC itself is included in the IF-RELEVANT (ID 1) portion of the authorization data in a ticket. Within the IF-RELEVANT portion, it is encoded as a KERB_AUTH_DATA_PAC with ID 128.

The PAC is defined as a C data type, with integers encoded in little-endian order. The PAC itself is made up of several layers. The outer structure, contained directly in the authorization data, is as follows. The top-level structure is the PACTYPE structure:

typedef unsigned long ULONG;
typedef unsigned short USHORT;
typedef unsigned long64 ULONG64;
typedef unsigned char UCHAR;
typedef struct _PACTYPE {
ULONG cBuffers;
ULONG Version;
PAC_INFO_BUFFER Buffers[1];
} PACTYPE;
The fields are defined as follows:
cBuffers - contains the number of entries in the array Buffers
Version - this is version zero
Buffers - contains a conformant array of PAC_INFO_BUFFER structures
The PAC_INFO_BUFFER structure contains information about each piece of the PAC:
typedef struct _PAC_INFO_BUFFER {
ULONG ulType;
ULONG cbBufferSize;
ULONG64 Offset;
} PAC_INFO_BUFFER;

Type fields are defined as follows:
ulType - contains the type of data contained in this buffer. For Windows 2000, it may be one of the following, which are explained further below:
#define PAC_LOGON_INFO 1
#define PAC_CREDENTIAL_TYPE 2
#define PAC_SERVER_CHECKSUM 6
#define PAC_PRIVSVR_CHECKSUM 7
#define PAC_CLIENT_INFO_TYPE 10

Offset - contains the offset to the beginning of the data, in bytes, from the beginning of the PACTYPE structure. The data offset must by a multiple of 8. If the data pointed to by this field is complex, the data is typically NDR encoded. If the data is simple (indicating it includes no pointer types or complex structures) it is a little-endian format data structure.

PAC Credential Information
PAC_INFO_BUFFERs of type PAC_LOGON_INFO contain the credential information for the client of the Kerberos ticket. The data itself is contained in a KERB_VALIDATION_INFO structure, which is NDR encoded. The output of the NDR encoding is placed in the PAC_INFO_BUFFER structure of type PAC_LOGON_INFO.
typedef struct _KERB_VALIDATION_INFO {
FILETIME LogonTime;
FILETIME LogoffTime;
FILETIME KickOffTime;
FILETIME PasswordLastSet;
FILETIME PasswordCanChange;
FILETIME PasswordMustChange;
UNICODE_STRING EffectiveName;
UNICODE_STRING FullName;
UNICODE_STRING LogonScript;
UNICODE_STRING ProfilePath;
UNICODE_STRING HomeDirectory;
UNICODE_STRING HomeDirectoryDrive;
USHORT LogonCount;
USHORT BadPasswordCount;
ULONG UserId;
ULONG PrimaryGroupId;
ULONG GroupCount;
[size_is(GroupCount)] PGROUP_MEMBERSHIP GroupIds;
ULONG UserFlags;
ULONG Reserved[4];
UNICODE_STRING LogonServer;
UNICODE_STRING LogonDomainName;
PSID LogonDomainId;
ULONG Reserved1[2];
ULONG UserAccountControl;
ULONG Reserved3[7];
ULONG SidCount;
[size_is(SidCount)] PKERB_SID_AND_ATTRIBUTES ExtraSids;
PSID ResourceGroupDomainSid;
ULONG ResourceGroupCount;
[size_is(ResourceGroupCount)] PGROUP_MEMBERSHIP ResourceGroupIds;
} KERB_VALIDATION_INFO;

The fields are defined as follows:
LogonTime - the time the client last logged on.
LogoffTime - the time at which the clients logon session should expire. If the logon session should not expire, this field should be set to (0x7fffffff,0xffffffff).
KickOffTime - the time at which the server should forcibly logoff the client. If the client should not be forced off, this field should be set to (0x7fffffff,0xffffffff). The ticket end time is a replacement for the
KickOffTime. The service ticket lifetime will never be longer than the KickOffTime for a user. PasswordLastSet - the time the clients password was last set. If it was never set, this field is zero.
PasswordCanChange - the time at which the clients password is allowed to change. If there is no restriction on when the client may change its password, this field should be set to the time of the logon.
PasswordMustChange - the time at which the clients password expires. If it doesnt expire, this field is set to (0x7fffffff,0xffffffff).
EffectiveName - This field contains the clients Windows 2000 UserName, stored in the Active Directory in the SamAccountName property. This field is optional. If left blank the length, maxlength and buffer are all zero.
FullName - this field contains the friendly name of the client, which is used only for display purpose and not security purposes. This field is optional. If left blank the length, maxlength and buffer are all zero.
LogonScript - This field contains the path to the clients logon script. This field is optional. If left blank the length, maxlength and buffer are all zero.
ProfilePath - This field contains the path to the clients profile. This field is optional. If left blank the length, maxlength and buffer are all zero.
HomeDirectory - This field contains the path to the clients home directory. It may be either a local path name or a UNC path name. This field is optional. If left blank the length, maxlength and buffer are all zero.
HomeDirectoryDrive - This field is only used if the clients home directory is a UNC path name. In that case, the share on the remote file server is mapped to the local drive letter specified by this field. This field is optional. If left blank the length, maxlength and buffer are all zero.
LogonCount - This field contains the count of how many times the client is currently logged on. This statistic is not accurately maintained by Windows 2000 and should not be used.
BadPasswordCount - This field contains the number of logon or password change attempts with bad passwords, since the last successful attempt.
* UserId - This field contains the relative Id for the client.
PrimaryGroupId - This field contains the relative ID for this clients primary group.
* GroupCount - This field contains the number of groups, within the clients domain, to which the client is a member.
* GroupIds - This field contains an array of the relative Ids and attributes of the groups in the clients
domain of which the client is a member.
* UserFlags - This field contains information about which fields in this structure are valid. The two bits that may be set are indicated below. Having these flags set indicates that the corresponding fields in the KERB_VALIDATION_INFO structure are present and valid.
#define LOGON_EXTRA_SIDS 0x0020
#define LOGON_RESOURCE_GROUPS 0x0200
LogonServer - This field contains the NETBIOS name of the KDC which performed the AS ticket request.
LogonDomainName - This field contains the NETBIOS name of the clients domain.
* LogonDomainId - This field contains the SID of the clients domain. This field is used in conjunction with the UserId, PrimaryGroupId,and GroupIds fields to create the user and group SIDs for the client.
UserAccountControl - This fields contains a bitfield of information about the clients account. Valid values are:
#define USER_ACCOUNT_DISABLED (0x00000001)
#define USER_HOME_DIRECTORY_REQUIRED (0x00000002)
#define USER_PASSWORD_NOT_REQUIRED (0x00000004)
#define USER_TEMP_DUPLICATE_ACCOUNT (0x00000008)
#define USER_NORMAL_ACCOUNT (0x00000010)
#define USER_MNS_LOGON_ACCOUNT (0x00000020)
#define USER_INTERDOMAIN_TRUST_ACCOUNT (0x00000040)
#define USER_WORKSTATION_TRUST_ACCOUNT (0x00000080)
#define USER_SERVER_TRUST_ACCOUNT (0x00000100)
#define USER_DONT_EXPIRE_PASSWORD (0x00000200)
#define USER_ACCOUNT_AUTO_LOCKED (0x00000400)
#define USER_ENCRYPTED_TEXT_PASSWORD_ALLOWED (0x00000800)
#define USER_SMARTCARD_REQUIRED (0x00001000)
#define USER_TRUSTED_FOR_DELEGATION (0x00002000)
#define USER_NOT_DELEGATED (0x00004000)
#define USER_USE_DES_KEY_ONLY (0x00008000)
#define USER_DONT_REQUIRE_PREAUTH (0x00010000)

* SidCount - This field contains the number of SIDs present in the ExtraSids field. This field is only valid if the LOGON_EXTRA_SIDS flag has been set in the UserFlags field.
* ExtraSids - This field contains a list of SIDs for groups to which the user is a member. This field is only valid if the LOGON_EXTRA_SIDS flag has been set in the UserFlags field.
* ResouceGroupCount - This field contains the number of resource groups in the ResourceGroupIds field. This field is only valid if the LOGON RESOURCE_GROUPS flag has been set in the UserFlags field._
* ResourceGroupDomainSid - This field contains the SID of the resource domain. This field is used in conjunction with the ResourceGroupIds field to create the group SIDs for the client.
* ResourceGroupIds - This field contains an array of the relative Ids and attributes of the groups in the resource domain of which the resource is a member.

Fields marked with a '*' are used in the NT token.

When used in the KERB_VALIDATION_INFO, this is NDR encoded. The FILETIME type is defined as follows:
typedef unsigned int DWORD;
typedef struct _FILETIME {
DWORD dwLowDateTime;
DWORD dwHighDateTime;
} FILETIME;

Times are encoded as the number of 100 nanosecond increments since January 1, 1601, in UTC time.
When used in the KERB_VALIDATION_INFO, this is NDR encoded. The UNICODE_STRING structure is defined as:

typedef struct _UNICODE_STRING
USHORT Length;
USHORT MaximumLength;
[size_is(MaximumLength / 2), length_is((Length) / 2) ] USHORT * Buffer;
} UNICODE_STRING;

The Length field contains the number of bytes in the string, not including the null terminator, and the MaximumLength field contains the total number of bytes in the buffer containing the string. The GROUP_MEMBERSHIP structure contains the relative ID of a group and the corresponding attributes for the group.

typedef struct _GROUP_MEMBERSHIP {
ULONG RelativeId;
ULONG Attributes;
} *PGROUP_MEMBERSHIP;

The group attributes must be:
#define SE_GROUP_MANDATORY (0x00000001L)
#define SE_GROUP_ENABLED_BY_DEFAULT (0x00000002L)
#define SE_GROUP_ENABLED (0x00000004L)
The SID structure is defined as follows:
typedef struct _SID_IDENTIFIER_AUTHORITY {
UCHAR Value[6];
} SID_IDENTIFIER_AUTHORITY, *PSID_IDENTIFIER_AUTHORITY;

The constant value for the NT Authority is:

#define SECURITY_NT_AUTHORITY {0,0,0,0,0,5}
typedef struct _SID {
UCHAR Revision;
UCHAR SubAuthorityCount;
SID_IDENTIFIER_AUTHORITY IdentifierAuthority;
[size_is(SubAuthorityCount)] ULONG SubAuthority[*];
} SID, *PSID;

The SubAuthorityCount field contains the number of elements in the actual SubAuthority conformant array. The maximum number of subauthorities allowed is 15.
The KERB_SID_AND_ATTRIBUTES structure contains entire group SIDs and their corresponding attributes:

typedef struct _KERB_SID_AND_ATTRIBUTES {
PSID Sid;
ULONG Attributes;
} KERB_SID_AND_ATTRIBUTES, *PKERB_SID_AND_ATTRIBUTES;

The attributes are the same as the group attributes defined above.

Client Information

The client information is included in the PAC to allow a server to verify that the PAC in a ticket is applicable to the client of the ticket, which prevents splicing of PACs between tickets. The PAC_CLIENT_INFO structure is included in a PAC_INFO_BUFFER of type PAC_CLIENT_INFO_TYPE.

typedef struct _PAC_CLIENT_INFO {
FILETIME ClientId;
USHORT NameLength;
WCHAR Name[1];
} PAC_CLIENT_INFO, *PPAC_CLIENT_INFO;

The fields are defined as follows:

ClientId - This field contains a conversion of the AuthTime field of the ticket into a FILETIME structure.
NameLength - This field contains the length, in bytes, of the Name field.
Name - This field contains the client name from the ticket, converted to Unicode and encoded using "/" to separate parts of the client principal name with an "@" separating the client principal name from the realm name. The string is not null terminated.

Supplemental Credentials

The KDC may return supplemental credentials in the PAC as well. Supplemental credentials are data associated with a security package that is private to that package. They can be used to return an appropriate user key that is specific to that package for the purposes of authentication. Supplemental creds are only used in conjunction with PKINIT[2]. Supplemental credentials are always encrypted using the client key. The PAC_CREDENTIAL_DATA structure is NDR encoded and then encrypted with the key used to encrypt the KDCs reply to the client. The PAC_CREDENTIAL_INFO structure is included in PAC_INFO_BUFFER of type PAC_CREDENTIAL_TYPE. Supplemental credentials for a single package are NDR encoded as follows:

typedef struct _SECPKG_SUPPLEMENTAL_CRED {
UNICODE_STRING PackageName;
ULONG CredentialSize;
[size_is(CredentialSize)]PUCHAR Credentials;
} SECPKG_SUPPLEMENTAL_CRED, *PSECPKG_SUPPLEMENTAL_CRED;

The fields in this structure are defined as follows:

PackageName - This field contains the name of the package for which credentials are presented.
CredentialSize - This field contains the length, in bytes, of the presented credentials.
Credentials - This field contains a pointer to the credential data.
The set of all supplemental credentials is NDR encoded in a PAC_CREDENTIAL_DATA structure:

typedef struct _PAC_CREDENTIAL_DATA {
ULONG CredentialCount;
[size_is(CredentialCount)] SECPKG_SUPPLEMENTAL_CRED Credentials[*];
} PAC_CREDENTIAL_DATA, *PPAC_CREDENTIAL_DATA;

The fields are defined as follows:

CredentialCount - This field contains the number of credential present in the Credentials array.
Credentials - This field contains an array of the presented supplemental credentials. The PAC_CREDENTIAL_DATA structure is NDR encoded and then encrypted with the key used to encrypt the KDC reply. The resulting buffer is returned in the following structure:
typedef struct _PAC_CREDENTIAL_INFO {
ULONG Version;
ULONG EncryptionType;
UCHAR Data[1];
} PAC_CREDENTIAL_INFO, *PPAC_CREDENTIAL_INFO;

The fields are defined as follows:
Version - This field contains the version field of the key used to encrypt the data, or zero if the field is not present.
EncryptType - This field contains the encryption type used to encrypt the data. The encryption type uses the same values as the defined encryptions types for Kerberos [1].
Data - This field contains an array of bytes containing the encrypted supplemental credential data.

Signatures

The PAC contains two digital signatures: one using the key of the server, and one using the key of the KDC. The signatures are present for two reasons. First, the signature with the servers key is present to prevent a client from generating their own PAC and sending it to the KDC as encrypted authorization data to be included in tickets. Second, the signature with the KDCs key is present to prevent an untrusted service from forging a ticket to itself with an invalid PAC. The two signatures are sent in PAC_INFO_BUFFERs of type PAC_SERVER_CHECKSUM and PAC_KDC_CHECKSUM respectively.

The signatures are contained in the following structure:

typedef struct _PAC_SIGNATURE_DATA {
ULONG SignatureType;
UCHAR Signature[1];
} PAC_SIGNATURE_DATA, *PPAC_SIGNATURE_DATA;

The fields are defined as follows:

SignatureType - This field contains the type of checksum used to create a signature. The checksum must be a keyed checksum.
Signature - This field consists of an array of bytes containing the checksum data. The length of bytes may be determined by the wrapping PAC_INFO_BUFFER structure.

For the servers checksum, the key used to generate the signature should be the same key used to encrypt the ticket. Thus, if the enc_tkt_in_skey option is used, the session key from the servers TGT should be used. The Key used to encrypt ticket-granting tickets is used to generate the KDCs checksum.

The checksums are computed as follows:

1. The complete PAC is built, including space for both checksums
2. The data portion of both checksums is zeroed.
3. The entire PAC structure is checksummed with the servers key, and the result is stored in the servers checksum structure.
4. The servers checksum is then checksummed with the KDC's key.
5. The checksum with the KDC key is stored in the KDC's checksum structure.

PAC Request Pre-Auth Data

Normally, the PAC is included in every pre-authenticated ticket received from an AS request. However, a client may also explicitly request either to include or to not include the PAC. This is done by sending the PAC-REQUEST preauth data.

KERB-PA-PAC-REQUEST ::= SEQUENCE {
include-pac[0] BOOLEAN -- if TRUE, and no PAC present,
-- include PAC.
---If FALSE, and PAC
-- present, remove PAC
}

The fields are defined as follows:
include-pac - This field indicates whether a PAC should be included or not. If the value is TRUE, a PAC will be included independent of other preauth data. If the value is FALSE, then no PAC will be included, even if other preauth data is present.

The preauth ID is:

#define KRB5_PADATA_PAC_REQUEST 128

References
1 Neuman, C., Kohl, J., Ts'o, T., "The Kerberos Network Authentication Service (V5)", draft-ietf-cat-kerberos-
revisions-05.txt, March 10, 2000
2 Tung, B., Hur, M., Medvinsky, A., Medvinsky, S., Wray, J., Trostle, J., " Public Key Cryptography for
Initial Authentication in Kerberos", draft-ietf-cat-kerberos-pk-init-11.txt, March 15, 2000


HTML and formatting errors are mine (Anonymous Coward's).

Ash (3, Interesting)

runswithd6s (65165) | more than 12 years ago | (#2579716)

Ever try ash [debian.org] ? Here's a size comparison just to intrigue you a bit.

(82780) /bin/ash*

(407356) /bin/bash*

As to distro startup scripts... (3, Informative)

Anomie-ous Cow-ard (18944) | more than 12 years ago | (#2579719)

Do you think that the startup scripts for most distributions would break because, even though they say #!/bin/sh at the top, they REALLY mean #!/bin/bash?

I couldn't say for other distros, but Debian policy [debian.org] says that /bin/sh can be any POSIX-compatible shell, with the one extension that 'echo -n' must not generate a newline. If any script uses /bin/sh assuming bash features, it's considered a serious-level bug.

Lamah! (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2579721)

If you spend as much time looking into bash as you did writing this non-issue ask-slashdot, maybe you could have answered your question without bothering me.

ksh: I built a ksh93 rpm (1)

dananderson (1880) | more than 12 years ago | (#2579729)

Just so you know, I built a ksh93 (the Korn shell) rpm. It's at http://dan.drydog.com/packages.php [drydog.com]

For information on Korn shell, see http://www.kornshell.com/ [kornshell.com]

With ksh, you can more easily interoperate with commercial UNIX systems, which now a days all come with ksh.

What's the problem? (1)

reynaert (264437) | more than 12 years ago | (#2579731)

I've read the list of differences in the FAQ. It's just a big list of extensions to the Bourne shell. It doesn't list any incompatibilities (except for a couple of obscure missing features which you probably shouldn't use anyway). If you write something in standard Bourne syntax, there should be no problems with Bash.

If you, on the other hand, test it with Bash, and then assume it will run under any other Unix... Well, you shouldn't do that with GNU software :)

ash (for debian, at least) doesn't work (2)

mikeage (119105) | more than 12 years ago | (#2579741)

I don't know the exact reason why... I barely know anything about shell scripting... but some shells that say /bin/sh will only work on my system if they use bash. Ash fails due to some difference in how it handles parentheses or file names or something... hopefully someone who knows shell scripting can elaborate ;)

Re:ash (for debian, at least) doesn't work (1)

psamuels (64397) | more than 12 years ago | (#2579766)

but some shells that say /bin/sh will only work on my system if they use bash. Ash fails due to some difference in how it handles parentheses or file names or something...

Are these scripts distributed with Debian? If so, file bugs - this sort of thing is Not Allowed. If they are third-party, same thing - file bugs, although a third-party script vendor may not care as much....

not quite right (2)

Cylix (55374) | more than 12 years ago | (#2579743)

"If bash is invoked with sh as its name (argv[0]) then its supposed to act like Bourne - but that just doesnt happen (for example: export FOO=bar is *not* valid Bourne shell syntax, you must say FOO=bar; export FOO)" Not quite right. the syntax export VAR=VALUE is a shorthand method. It is still perfectly alright to VAR=VALUE and then export VAR. I've not run into a comptability problem running scripts under bash, but that does not mean they exist. You can of course recompile bash to function differently ie, for statements can act more like C for statements then their bash versions. Still, tinkering with your shell nulls all warranties, in a sense anyway. Bash has a huge install base and is most likely the shell you will find on most linux systems. If you are really interested in supporting it, you will most likely have to code around its problems. ie, doing a revision check and using X function instead of Y.

cmdr Taco has sexual dysfunction (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2579745)

Many of you know that cmdr Taco
and I had a date last night in
Rock Creek Park. I fucked him
good and he liked it allright. He's
quite a considerate lover, he
licked his own shit clumps off
my dick each time after I'd throttled
his hairy arse.

However, when it was my turn get fucked
hard, he couldn't perform! Poor bastard.
He's almost as worthless as that fucking
stupid queer cowboy neil.

P.S. Solaris8 forever!!

Debian uses ash. (1)

BubbaFett (47115) | more than 12 years ago | (#2579747)

Debian kernels are now compiled with initrd support. They use ash for their kernel boot scripts. I'm guessing this is because of it's size.

Re:Debian uses ash. (2)

PigleT (28894) | more than 12 years ago | (#2579772)

Last I checked, it wasn't just the size, at all, but the whole POSIX-compliance/bourne-compat thing, anyway.

Besides, given my experiences with "bourne" on AIX/Slowlaris/HP/whatever, I'd be quite happy for the whole concept to die a horrible death, standardise on simple bash and have done.

That's like Jumbo Shrimp (2)

john@iastate.edu (113202) | more than 12 years ago | (#2579835)

... standardise on simple bash ...

Simple bash -- A phrase I'd never expect to hear!
On my system:
131072 sh
688128 bash

Re:Debian uses ash. (1)

psamuels (64397) | more than 12 years ago | (#2579774)

Debian kernels are now compiled with initrd support.

Now compiled? They have had initrd support for as long as I can remember (1996? 1997?).

They use ash for their kernel boot scripts. I'm guessing this is because of it's [sic] size.

Boot scripts (what is a "kernel boot script"?) can be in either bash or sh, but if they declare #!/bin/sh they must not use any non-POSIX-isms. The installation floppies use ash, because of its size. Recently someone proposed using the built-in shell from Busybox, but that may not happen because of robustness / compatibility.

Re:Debian uses ash. (1)

BubbaFett (47115) | more than 12 years ago | (#2579822)

Now compiled? They have had initrd support for as long as I can remember (1996? 1997?).

Well, maybe they have, I don't know. I've never tinkered with it, but the packages in testing now depend on initrd-tools, which in turn depend on ash.

Let *sh die! (-1, Troll)

Anonymous Coward | more than 12 years ago | (#2579752)

The shell scripting languages need to die. I find a more enlightened approach is to integrate a full interpreted language like perl or python into a shell-like environment. I like what psh is doing in this regards - work just like you are in a traditional shell, but have available all the facillities of perl.

And which "real Bourne shell" would that be? (4, Insightful)

mj6798 (514047) | more than 12 years ago | (#2579760)

There have been lots of different versions of the "real Bourne shell" over the years. From a practical point of view, you should have no problem writing scripts that run in bash and in whatever shell you consider "real". Stick to the POSIX specs where possible.

However, why are you writing "installer scripts" anyway? If you want to deliver on Linux, please use the Linux packaging system. If you deliver on Solaris, please use the Solaris packaging system. Etc.

Re:And which "real Bourne shell" would that be? (1)

mikec (7785) | more than 12 years ago | (#2579785)

I'm curious. What, exactly, is the Linux packaging system?

-mike

Re:And which "real Bourne shell" would that be? (2)

swillden (191260) | more than 12 years ago | (#2579789)

If you want to deliver on Linux, please use the Linux packaging system.

What is the Linux packaging system?

Re:And which "real Bourne shell" would that be? (1)

TicTacTux (99149) | more than 12 years ago | (#2579808)

tgz. rpm. No, wait, .deb. Er, that is, .tar.bz2. Or was it .zip? Dang, I had it on the tip of my tongue - cat <<EOF? .Z? A, now I have it: x-application/linuxpackage!

Use the source, Luke! (sic! ed.)

Re:And which "real Bourne shell" would that be? (2, Interesting)

psamuels (64397) | more than 12 years ago | (#2579799)

However, why are you writing "installer scripts" anyway? If you want to deliver on Linux, please use the Linux packaging system. If you deliver on Solaris, please use the Solaris packaging system. Etc.

The Linux packaging system? There are several, at least three of which (rpm, deb, tgz) are in common use.

It's a valid question, but there are a lot of packaging systems out there - the ones for AIX, HP-UX and IRIX don't resemble each other in the least. Besides, while I don't mind installing packages on AIX or IRIX, the HP-UX 'depot' format and supporting tools are so clumsy that I'd rather run a vendor install script, and worry about uninstalling "manually", any day of the week. (In practice, vendors like Dassault, PTC and MSC never use the native install format - they always supply a script. And that script always seems to assume POSIX shell features. It is also always poorly-written, but that's a different rant.)

Re:And which "real Bourne shell" would that be? (2)

talonyx (125221) | more than 12 years ago | (#2579802)

The Linux Packaging System?

Sorry, but do you mean deb files, or rpm's, or perhaps a gzipped tarball with a makefile inside?

When there's no real set standard, it's fine to write an install script. Plenty of programs do it.

Not much choice, is there? (1)

mikec (7785) | more than 12 years ago | (#2579773)

You have to use /bin/sh and test on all platforms. There isn't anything else you can rely rely on finding on all distributions. Yes, there are probably slight differences between what purports to be /bin/sh on various platforms, but I can't imagine it will be very hard to write a script that runs fine under all of them---just avoid the dark corners.

Suggestions for other shells (ash or whatever) that might be better are pointless for your purposes because you can't rely on them being there.

Bash versions with bugs (1)

Croooow (182767) | more than 12 years ago | (#2579780)

I know from experience that (some?) 1.x Bash versions have a bug in the getopt builtin. The bug seems to be fixed in 2.x versions (not sure what version fixed it). There is a workaround for the bug, but it breaks portability of the script. The workaround also causes the script to break for fixed versions of Bash.

/bin/bash? (0)

Anonymous Coward | more than 12 years ago | (#2579782)

That's absurd. You don't have any problem with !#/bin/bash ?

I do. I don't have /bin/bash

If you don't require any bash extentions, run the script with /bin/sh - we'll leave the where does bash belong debate for another day, but if you wrote an sh script, run it with sh, it's as simple as that.

It's not my fault Joe Linux Distro doesn't include a regular sh.

Linux ash == BSD sh? (1)

BubbaFett (47115) | more than 12 years ago | (#2579783)

From what I can tell from the documentation and man page, ash is just BSD's /bin/sh. Do the BSDs use GNU Bash, assuming the admin wants Bash on the system at all?

The solution is... (0, Troll)

aminorex (141494) | more than 12 years ago | (#2579794)

...submit a fucking patch, dickwad.
Sheesh. Some people's kids!

a real bourne shell (0, Troll)

super-flex-o-matic (517410) | more than 12 years ago | (#2579797)

is the last thing linux needs to succeed at the moment.

so why ask for people to write one, if it lacks in totally different places.

a question from me maybe:
is it possible to scale linux down, put (insert the most user-friendly windowmanager here) in it, and keep all those server stuff (appache, bind etc.) out put it on one cd, make an easy installer with good hardware detection, make a framework that 3rd party software vendors can work on without colliding with the GPL's issues, eye candy - multiuser support. and ease the pain of windows users.

ah ya, and dont forget to write a script that makes the delete and backspace buttons work under every terminal-emulator.

Re:a real bourne shell (1)

psamuels (64397) | more than 12 years ago | (#2579810)

is it possible to scale linux down, put (insert the most user-friendly windowmanager here) in it, and keep all those server stuff (appache, bind etc.) out put it on one cd, make an easy installer with good hardware detection, make a framework that 3rd party software vendors can work on

The one requirement you forgot was "and get it noticed by the media so that people will even know it exists". There are scores of Linux distributions, and more than a few were created with exactly these goals (SEUL for one), but you'll never hear about them on CNET.

ah ya, and dont forget to write a script that makes the delete and backspace buttons work under every terminal-emulator.

Use Debian, they actually have a "delete/backspace policy" that covers this. Of course, all bets are off when you use said terminal to telnet to a non-Debian system - that's a problem you just can't solve without cooperation from vendors....

Which direction are you worried about? (5, Interesting)

MarkusQ (450076) | more than 12 years ago | (#2579804)

I think that there is some confusion here. The_code_poet clearly asked about compatibility going from sh to bash (i.e., he wants to write standard sh scripts and have them work on linux, and therefore bash). But the incompatibilities everyone is discussing (e.g. initialized export syntax) are all going the other way; things that you can write under bash that won't work under sh. So what?

The things that matter are first, the things sh has that bash does not (from the FAQ):

* uses variable SHACCT to do shell accounting
* includes `stop' builtin (bash can use alias stop='kill -s STOP')
* `newgrp' builtin
* turns on job control if called as `jsh'
* $TIMEOUT (like bash $TMOUT)
* `^' is a synonym for `|' * new SVR4.2 sh builtins: mldmode, priv

...and the implementation differences:

* redirection to/from compound commands causes sh to create a subshell
* bash does not allow unbalanced quotes; sh silently inserts them at EOF
* bash does not mess with signal 11
* sh sets (euid, egid) to (uid, gid) if -p not supplied and uid < 100
* bash splits only the results of expansions on IFS, using POSIX.2 field splitting rules; sh splits all words on IFS
* sh does not allow MAILCHECK to be unset (?)
* sh does not allow traps on SIGALRM or SIGCHLD
* bash allows multiple option arguments when invoked (e.g. -x -v); sh allows only a single option argument (`sh -x -v' attempts to open a file named `-v', and, on SunOS 4.1.4, dumps core. On Solaris 2.4 and earlier versions, sh goes into an infinite loop.)
* sh exits a script if any builtin fails; bash exits only if one of the POSIX.2 `special' builtins fails

None of these seem to me to be show-stoppers if you are writing the script from scratch (or even porting a reasonably written one)--I mean really, are you counting on it to dump core if you use multiple option arguments? Is there some reason you can't ballane your quotes? So my question to the_code_poet is, what exactly are you trying to do in sh that won't work in bash?

--MarkusQ

Can you blame 'em? (0, Troll)

imrdkl (302224) | more than 12 years ago | (#2579811)

For making a shell that is incompatible with non-free OS?

What this story needs (-1, Offtopic)

Anonymous Coward | more than 12 years ago | (#2579813)

is a goatse.cx [goatse.cx] link.

And your full POSIX.1 and .2 docs are... (0)

Anonymous Coward | more than 12 years ago | (#2579820)


right here [debian.org] , free for everyone to download.

Or actually, this is what _will_ be POSIX next year or so.

"START PROGRAMING PORTABLY!!", to quote that post.

Never thought I'd see it. (1)

GISboy (533907) | more than 12 years ago | (#2579824)

bashing microsoft, I believe.

But bashing bash?

As a current tcsh user under OS X I feel the need to be Bourne again.

i wonder if there is a bashdot.org..I'll go look.

(j/k)

Will the Real Bourne Shell Please Stand Up? (1)

John Hasler (414242) | more than 12 years ago | (#2579836)

"would anyone out there be interested in writing a real Bourne Shell for Linux?"

First you will have to tell us what a "real" Bourne shell is. It's not as if there is a standard.

You might or might not like ash. It is much smaller than bash, but on the other hand it tries even harder than bash to be POSIX compliant.

What the author really wants is a POSIX-only Shell (2)

fwc (168330) | more than 12 years ago | (#2579842)

Obviously what the author wants is a shell which implements just the POSIX standard and nothing else. Or maybe expanding just a little bit, wants a shell which JUST implements the Bourne syntax which is available in all Bourne-compatible shells.

I can understand the reason for this when writing an install script - specifically it is desirable to write to the lowest common denominator and thus make it compatible with everything.

However, I can't think of a single shell which actually implements just POSIX, or Bourne syntax for that matter. There are dozens of shells out there which all will chew on a real POSIX or Bourne script and spit out something which is pretty close to what the script author intended. However it seems that all of the shell authors have done stuff a little differently than each other so if you've only written and tested on one shell, you might have problems running on any one (or all) of the other shell(s).

The best thing to do is to pick something small which is as close to just POSIX implementation as you can get (ash perhaps?) and write/develop in that shell and then thouroughly test it on things like bash, ksh and other POSIX shells.

I always like to through out the fact that most systems now have perl available on them and in some cases it is probably just as appropriate if not more so to script install stuff in perl.

If you want a standard, try pushing FORWARD (0)

Anonymous Coward | more than 12 years ago | (#2579860)

solaris sucks - because it doesn't come with bash.

It's ok saying "I want it to be portable, but linux and BSD don't have a proper shell like the archaic solaris and Xenix systems". How about getting sun to install a half-usable shell by default on their systems then? Then you can write "/bin/bash" at the top of your script and know that you're using a defacto standard. Alternately, a bunch of linux coders could waste their time writing an inferior shell.

Time to get your pension, guys.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>