On 28 Aug 2008 22:59:41 +0200,
Mark Madsen wrote:
> On Thu, 28 Aug 2008 13:19:15 +0000, jpd wrote:
>
>> Why you'd want to ``banish sh'' is unclear to me. The system needs sh,
>> and as you say you only want to use bash as your login shell
>
> Not that I'm defending the OP or their actions so far(*), but several
> people posting in this thread seem unaware that bash is designed to
> behave as "sh" (and not as bash) when it is called as "sh". Note I say
> "designed to". I haven't tested it thoroughly enough to say. Just a
> point of information.

Point taken. Counterpoint: The supplied sh is what the scripts are
tested with, and the church of gnu isn't known for maintaining
compatability with what was cool last week. FreeBSD's maintainers will
laugh at you if you complain any system supplied script fails in some
obscure way, however minor, if you've replaced the shell it was supposed
to run with, with some other shell of your choosing. Summing up:

For the sake of stability, predictability, and avoiding ire and mirth
at your expense when asking for help, don't go play doctor with a rusty
knife on your system's /bin/sh.


Since the OP _has_ been asking quite a lot, lately, asking to at least
keep a stock /bin/sh doesn't seem unjustified.


> (*) I doubt that I would do what they did on a system of my own, and I
> can't imagine caring that much, but people have inexplicably strong
> preferences about stuff like shells and text editors.

Yes, and on their own user account that isn't a problem at all, in fact,
the system provides a simple mechanism to support that. As root, the notion
is silly and not without risk. Replacing the /bin/sh binary with something
else just so you can have a different shell for your normal user's login
seems entirely misguided seeing as there is a damage-free way already.


Of course, I'm from almost the exact opposite of the spectrum now: Having
to work on unconfigured systems with different shells, under pressure and
no manual in sight teaches to reduce assumptions to the bare minimum. I'm
usually pretty happy if tab works and up/down arrow accesses the history.

So I'm back at using whatever is the default shell, and I can't be
bothered to install another and chsh even for my normal user account.
My current .cshrc differs from stock by setting a custom interactive
prompt, a few environment variables, and time=5. That is about it.

Thinking about it, ~/bin contains a couple of scripts, some of which
might've better been written as aliases, but, well. Maybe another day.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

Mark Madsen wrote:
> Not that I'm defending the OP or their actions so far(*), but several
> people posting in this thread seem unaware that bash is designed to
> behave as "sh" (and not as bash) when it is called as "sh". Note I say
> "designed to". I haven't tested it thoroughly enough to say. Just a
> point of information.

And for those who haven't experienced the 'sh' mode of bash; it is
about 99% compatible with a real 'sh' shell.
It breaks in a few spectacular ways, for example by letting incompatible
bashisms[1] through.
This is particularly bad if somebody is testing say, their configure or
automake scripts for a program with bash in 'sh' mode, finds out that it
works just fine, packages and distributes their latest release only to
find out from the feedback that both the configure script, and the
automake scripts break on systems with a real 'sh' shell because of said
bashisms.

Most recent experience: aMule version 2.2.2 (yes, the developers know
about it and will fix it.)

References:
1) http://en.wikipedia.org/wiki/Bashism
--
Torfinn Ingolfsen,
Norway

drew@furrfu.invalid (Drew Lawson) writes:

> You mean that you have tested all of the FreeBSD Bourne shell scripts
> and confirmed that they work correctly in bash? All of them?
> Periodic? Make subshells? Ports? All the other subpieces that
> I'm not aware of?
>
> I find it hard to believe that you've exercised the system that
> fully and still didn't have enough familiarity to edit /etc/shells.
>
> None of this is saying that bash is broken or lesser. I don't use
> it, but I was under the impression that there are bits and pieces
> that are intentionally different than sh. Any one of those could
> affect how a script that you don't know about runs.

I don't claim to be an expert either on old sh or bash, but isn't one
of the ideas behind bash to do sh compatible shell - only better?

BTW I have used bash in this role now (unless I misunderstood the OP)
for a few years (since 5.2) and it seems to work fine.

/Andreas

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

On Fri, 29 Aug 2008 11:26:31 -0400,
Andreas Davour wrote:
>
> I don't claim to be an expert either on old sh or bash, but isn't one
> of the ideas behind bash to do sh compatible shell - only better?

It's a nice theory in theory, but in practice, there are a couple of
issues with it. You can find quite a few mentioned in the thread. Most
of the issues relevant to this tread can be summed up by noting that
there is quite a sizeable rest of the world who haven't drunk the
gn00/b4sh kool-aid. In the ``only we're better'' view that automagically
blames the rest of the world. Guess who doesn't quite agree?

Telling is also that various linux distribution folks got fed up with
bash and are moving (or have moved) to dash.


> BTW I have used bash in this role now (unless I misunderstood the OP)
> for a few years (since 5.2) and it seems to work fine.

- You can use it for your login shell just fine.
- There are issues with using it (or anything but the default) for root's
login shell.
- There are more issues with removing the stock /bin/sh then making the
bash binary available under that pathname.

Even if the last point ``seems to work fine'' (but is not unlikely to
turn around and bite when, say, you're trying to resurect a system in
single-user-/bin/sh-console-mode), it's not supported. But that point
too was discussed upthread already.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.

Andreas Davour wrote:
> I don't claim to be an expert either on old sh or bash, but isn't one
> of the ideas behind bash to do sh compatible shell - only better?

It is.

It is also widely known that the real thing falls short of this goal.
Just how close it is is matter of much debate.

And aside from compatibility issues bash is huge, chunky, takes eons
to compile and is generally less suited for a role as minimum standard
shell scripting platform the way /bin/sh is.

Not to mention the twelve thousand threehundred and sixty-seven penguin-
loving coders who keep adding their latest and greatest feature to its
already impressive feature set.

Bash is fine a a personal login shell, but aside from linux purism
there is hardly any reason to have it as /bin/sh replacement.

For the two times per year you actually have to use /bin/sh give it
set -o emacs and you get command line editing and arrow keys history
the way you are used to. That should give you enough comfort to
survive the encounter.

Regards

Christoph Weber-Fahr

Andreas Davour writes:

> drew@furrfu.invalid (Drew Lawson) writes:
>
> > You mean that you have tested all of the FreeBSD Bourne shell scripts
> > and confirmed that they work correctly in bash? All of them?
> > Periodic? Make subshells? Ports? All the other subpieces that
> > I'm not aware of?
> >
> > I find it hard to believe that you've exercised the system that
> > fully and still didn't have enough familiarity to edit /etc/shells.
> >
> > None of this is saying that bash is broken or lesser. I don't use
> > it, but I was under the impression that there are bits and pieces
> > that are intentionally different than sh. Any one of those could
> > affect how a script that you don't know about runs.
>
> I don't claim to be an expert either on old sh or bash, but isn't one
> of the ideas behind bash to do sh compatible shell - only better?
>
> BTW I have used bash in this role now (unless I misunderstood the OP)
> for a few years (since 5.2) and it seems to work fine.


Pretending bash is sh is not a good plan. sh only takes 106k of your
disk space. If you lose your /usr partition or run into some
mysterious problem with a script, it could save you a lot of time.
If you must log in as root so often that running bash as a subshell
seems desirable, a better approach would be to use the toor login and
change toor's login shell to bash.

-- Patrick

On 08/29/2008 08:56 PM, Andreas Davour wrote:
> drew@furrfu.invalid (Drew Lawson) writes:
>
>> You mean that you have tested all of the FreeBSD Bourne shell scripts
>> and confirmed that they work correctly in bash? All of them?
>> Periodic? Make subshells? Ports? All the other subpieces that
>> I'm not aware of?
>>
>> I find it hard to believe that you've exercised the system that
>> fully and still didn't have enough familiarity to edit /etc/shells.
>>
>> None of this is saying that bash is broken or lesser. I don't use
>> it, but I was under the impression that there are bits and pieces
>> that are intentionally different than sh. Any one of those could
>> affect how a script that you don't know about runs.
>
> I don't claim to be an expert either on old sh or bash, but isn't one
> of the ideas behind bash to do sh compatible shell - only better?
>
> BTW I have used bash in this role now (unless I misunderstood the OP)
> for a few years (since 5.2) and it seems to work fine.

but the manpage of bash has a decent section:

BUGS
It’s too big and too slow.

There are some subtle differences between bash and traditional
versions of sh, mostly because of the POSIX specification.

Aliases are confusing in some uses.

Shell builtin commands and functions are not stoppable/restartable.

Compound commands and command sequences of the form ‘a ; b ; c’ are
not handled gracefully when process suspension is attempted. When
a process is stopped, the shell immediately executes the next command
in the sequence. It suffices to place the sequence of commands
between parentheses to force it into a subshell, which may be stopped
as a unit.

Commands inside of $(...) command substitution are not parsed
until substitution is attempted. This will delay error reporting
until some time after the command is entered. For example, unmatched
parentheses, even inside shell comments, will result in error
messages while the construct is being read.

Array variables may not (yet) be exported.


I'm no one to distract you and, or anyone else from using bash, but one
should be aware enough that why one is using or wants to use a bigger
and slower shell for routine and, or system scripts or regular user
interactions.

--
Dr Balwinder S "bsd" Dheeman Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe) Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India Gentoo, Fedora, Debian/FreeBSD/XP
Home: http://cto.homelinux.net/~bsd/ Visit: http://counter.li.org/

On Fri, 29 Aug 2008 22:24:03 -0700, kkt wrote:

>
> Pretending bash is sh is not a good plan. sh only takes 106k of your
> disk space. If you lose your /usr partition or run into some mysterious
> problem with a script, it could save you a lot of time. If you must log
> in as root so often that running bash as a subshell seems desirable, a
> better approach would be to use the toor login and change toor's login
> shell to bash.
>
> -- Patrick

This sounds rather like superstition. There is more chance of me winning
the national lottery than anything as arcance as this happening.

On Sat, 30 Aug 2008 19:00:03 UTC, NVangogh
wrote:

> On Fri, 29 Aug 2008 22:24:03 -0700, kkt wrote:
>
> >
> > Pretending bash is sh is not a good plan. sh only takes 106k of your
> > disk space. If you lose your /usr partition or run into some mysterious
> > problem with a script, it could save you a lot of time. If you must log
> > in as root so often that running bash as a subshell seems desirable, a
> > better approach would be to use the toor login and change toor's login
> > shell to bash.
> >
> > -- Patrick
>
> This sounds rather like superstition. There is more chance of me winning
> the national lottery than anything as arcance as this happening.

If that is your belief, then go ahead.

--
Bob Eager
UNIX since v6..
http://tinyurl.com/2xqr6h

NVangogh wrote:
>> Pretending bash is sh is not a good plan. sh only takes 106k of your
>> disk space. If you lose your /usr partition or run into some mysterious
>> problem with a script, it could save you a lot of time. If you must log
>> in as root so often that running bash as a subshell seems desirable, a
>> better approach would be to use the toor login and change toor's login
>> shell to bash.
>
>This sounds rather like superstition. There is more chance of me winning
>the national lottery than anything as arcance as this happening.

It is as much legacy as superstiton. See also
.

Roger Marquis

NVangogh writes:

> On Fri, 29 Aug 2008 22:24:03 -0700, kkt wrote:
>
> >
> > Pretending bash is sh is not a good plan. sh only takes 106k of your
> > disk space. If you lose your /usr partition or run into some mysterious
> > problem with a script, it could save you a lot of time. If you must log
> > in as root so often that running bash as a subshell seems desirable, a
> > better approach would be to use the toor login and change toor's login
> > shell to bash.
> >
> > -- Patrick
>
> This sounds rather like superstition. There is more chance of me winning
> the national lottery than anything as arcance as this happening.

Hey, if you seek good advice from a newsgroup and then ignore it, it's
your system. Fact remains, there's several risks associated with
changing root's shell, and you could have just as much convenience and
no risk by using toor.

-- Patrick

kkt wrote:
> NVangogh writes:

>> This sounds rather like superstition. There is more chance of me winning
>> the national lottery than anything as arcance as this happening.

> Hey, if you seek good advice from a newsgroup and then ignore it, it's
> your system. ...

"Well," Brahma said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent man requires only two thousand five hundred."

Balwinder S Dheeman writes:

> On 08/29/2008 08:56 PM, Andreas Davour wrote:
>> drew@furrfu.invalid (Drew Lawson) writes:
>>
>>> You mean that you have tested all of the FreeBSD Bourne shell scripts
>>> and confirmed that they work correctly in bash? All of them?
>>> Periodic? Make subshells? Ports? All the other subpieces that
>>> I'm not aware of?
>>>
>>> I find it hard to believe that you've exercised the system that
>>> fully and still didn't have enough familiarity to edit /etc/shells.
>>>
>>> None of this is saying that bash is broken or lesser. I don't use
>>> it, but I was under the impression that there are bits and pieces
>>> that are intentionally different than sh. Any one of those could
>>> affect how a script that you don't know about runs.
>>
>> I don't claim to be an expert either on old sh or bash, but isn't one
>> of the ideas behind bash to do sh compatible shell - only better?
>>
>> BTW I have used bash in this role now (unless I misunderstood the OP)
>> for a few years (since 5.2) and it seems to work fine.
>
> but the manpage of bash has a decent section:
>
> BUGS
[snip]

> I'm no one to distract you and, or anyone else from using bash, but one
> should be aware enough that why one is using or wants to use a bigger
> and slower shell for routine and, or system scripts or regular user
> interactions.

Fun. I had not ever read that far in the man page, since I mainly use
it for lookup things.

/andreas

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

kkt writes:

> Andreas Davour writes:
>
>> drew@furrfu.invalid (Drew Lawson) writes:
>>
>> > You mean that you have tested all of the FreeBSD Bourne shell scripts
>> > and confirmed that they work correctly in bash? All of them?
>> > Periodic? Make subshells? Ports? All the other subpieces that
>> > I'm not aware of?
>> >
>> > I find it hard to believe that you've exercised the system that
>> > fully and still didn't have enough familiarity to edit /etc/shells.
>> >
>> > None of this is saying that bash is broken or lesser. I don't use
>> > it, but I was under the impression that there are bits and pieces
>> > that are intentionally different than sh. Any one of those could
>> > affect how a script that you don't know about runs.
>>
>> I don't claim to be an expert either on old sh or bash, but isn't one
>> of the ideas behind bash to do sh compatible shell - only better?
>>
>> BTW I have used bash in this role now (unless I misunderstood the OP)
>> for a few years (since 5.2) and it seems to work fine.
>
>
> Pretending bash is sh is not a good plan. sh only takes 106k of your
> disk space. If you lose your /usr partition or run into some
> mysterious problem with a script, it could save you a lot of time.
> If you must log in as root so often that running bash as a subshell
> seems desirable, a better approach would be to use the toor login and
> change toor's login shell to bash.

Apparently I had misunderstood the OP. Pretending bash is sh is not a
good plan, agree.

/andreas

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

Christoph Weber-Fahr writes:

> Andreas Davour wrote:
>> I don't claim to be an expert either on old sh or bash, but isn't one
>> of the ideas behind bash to do sh compatible shell - only better?
>
> It is.
>
> It is also widely known that the real thing falls short of this goal.
> Just how close it is is matter of much debate.
>
> And aside from compatibility issues bash is huge, chunky, takes eons
> to compile and is generally less suited for a role as minimum standard
> shell scripting platform the way /bin/sh is.
>
> Not to mention the twelve thousand threehundred and sixty-seven penguin-
> loving coders who keep adding their latest and greatest feature to its
> already impressive feature set.
>
> Bash is fine a a personal login shell, but aside from linux purism
> there is hardly any reason to have it as /bin/sh replacement.

Well there is a reason I use FreeBSD and not Linux.

I did think that the issue was of using bash for root, not replacing
/bin/sh. That is a bad idea, yes.

/Andreas

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

jpd writes:

> On Fri, 29 Aug 2008 11:26:31 -0400,
> Andreas Davour wrote:
>>
>> I don't claim to be an expert either on old sh or bash, but isn't one
>> of the ideas behind bash to do sh compatible shell - only better?
>
> It's a nice theory in theory, but in practice, there are a couple of
> issues with it. You can find quite a few mentioned in the thread. Most
> of the issues relevant to this tread can be summed up by noting that
> there is quite a sizeable rest of the world who haven't drunk the
> gn00/b4sh kool-aid. In the ``only we're better'' view that automagically
> blames the rest of the world. Guess who doesn't quite agree?
>
> Telling is also that various linux distribution folks got fed up with
> bash and are moving (or have moved) to dash.
>
>
>> BTW I have used bash in this role now (unless I misunderstood the OP)
>> for a few years (since 5.2) and it seems to work fine.
>
> - You can use it for your login shell just fine.
> - There are issues with using it (or anything but the default) for root's
> login shell.
> - There are more issues with removing the stock /bin/sh then making the
> bash binary available under that pathname.
>
> Even if the last point ``seems to work fine'' (but is not unlikely to
> turn around and bite when, say, you're trying to resurect a system in
> single-user-/bin/sh-console-mode), it's not supported. But that point
> too was discussed upthread already.

Point number three I fully agree with. I must have misunderstood the
OP, as I said.

Point number two is where I think that it "seem to work fine", but
maybe I've just been lucky. Or I missed some fine point again.

/Andreas

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?