der Mouse | 1 Jan 2011 01:43

Re: mksh import

> I think that it would be good to have at least one modern shell in
> our base, [...]

What meaning of "modern" are you using here?

Lots of people use "modern" this way, but I've seen almost as many
meanings as I have people using it, so I no longer trust myself to
understand what anyone using it actually means.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse <at> rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

David Young | 1 Jan 2011 02:00
Picon
Favicon

Re: mksh import

On Thu, Dec 30, 2010 at 10:17:42AM +0100, Adam Hamsik wrote:
> Hi folks,
> 
> I think that it would be good to have at least one modern shell in
> our base, because I use ksh and it's de facto standard I have decided
> to make a patch which adds mksh[1] to our base [2]. Code is BSD
> licensed, well written and maintained which can't be said about our
> own ksh(There are 15 PRs opened for it).

What is it that you mean by "modern shell" ?

Dave

--

-- 
David Young             OJC Technologies
dyoung <at> ojctech.com      Urbana, IL * (217) 278-3933

Alex Goncharov | 1 Jan 2011 03:15
Picon

Re: mksh import

,--- der Mouse (Fri, 31 Dec 2010 19:43:26 -0500 (EST)) ----*
| > I think that it would be good to have at least one modern shell in
| > our base, [...]
| What meaning of "modern" are you using here?
,--- David Young (Fri, 31 Dec 2010 19:00:43 -0600) ----*
| What is it that you mean by "modern shell" ?
`------------------------------------------------------*

Let me try to offer you a user's perspective.

I spend a significant part of my work day at shell prompts, working
with various OSes.  Another noticeable part of my time is spent
writing shell scripts.

And, any day of the week, I could say, "Thank God, Bash exists!.."

I don't care much (remember, I am a user, not an OS provider, which
would be a different story) about the strict /bin/sh or POSIX.N
compatibility.  Neither I, nor most of the (very skilled) people
around myself would be able to correctly explain what that means.

With Bash, I have a uniform and extremely efficient environment for
both command line manipulation and scripting; I don't have to use one
shell for the former and another for the latter -- thus, I can perfect
my shell mastery all the time, naturally.  I can use (or build) Bash
on any of the many platforms I work with -- and the same version of it
will behave the same elsewhere.  It also helps that Bash is:

  * Constantly evolving, adding new powerful features;

(Continue reading)

David Laight | 1 Jan 2011 12:52
Picon

Re: mksh import

On Fri, Dec 31, 2010 at 09:15:47PM -0500, Alex Goncharov wrote:
> Let me try to offer you a user's perspective.
> 
> I spend a significant part of my work day at shell prompts, working
> with various OSes.  Another noticeable part of my time is spent
> writing shell scripts.
> 
> And, any day of the week, I could say, "Thank God, Bash exists!.."

Actually I've written quite a lot of scripts and use long command lines,
(and have done so for many, many years) and rather wish that bash
didn't exst!

> I don't care much (remember, I am a user, not an OS provider, which
> would be a different story) about the strict /bin/sh or POSIX.N
> compatibility.  Neither I, nor most of the (very skilled) people
> around myself would be able to correctly explain what that means.

If you want to write scripts that are portable between machines, you
need to ensure that you only use the 'posix' features.
Unfortunately bash doesn't implement some of them, and has a lot of
non-standard extensions that really just cause portability issues.

If you really want portability you need to restrict yourself to the
'traditional' bourne shell (eg /bin/sh on solaris). That doesn't
stop you writing complex scripts, but does require lateral thought
to avoid the costs of running 'expr' (etc).

> With Bash, I have a uniform and extremely efficient environment for
> both command line manipulation and scripting;
(Continue reading)

Alex Goncharov | 1 Jan 2011 14:41
Picon

Re: mksh import

,--- You/David (Sat, 1 Jan 2011 11:52:43 +0000) ----*
| On Fri, Dec 31, 2010 at 09:15:47PM -0500, Alex Goncharov wrote:
| > Let me try to offer you a user's perspective.

Note that: "a user's perspective".  I use what I find best working for
me and am just trying to share the experience -- feel free to
disregard.

And, these days, I am not using NetBSD at all; make what you want of it.

| Actually I've written quite a lot of scripts and use long command lines,
| (and have done so for many, many years) and rather wish that bash
| didn't exst!

Its existence doesn't force you use it.

| > I don't care much (remember, I am a user, not an OS provider, which
| > would be a different story) about the strict /bin/sh or POSIX.N
| > compatibility.  Neither I, nor most of the (very skilled) people
| > around myself would be able to correctly explain what that means.
| 
| If you want to write scripts that are portable between machines, you
| need to ensure that you only use the 'posix' features.

No: I only need to have the same version of the interpreter (Bash)
installed on all machines.  Which is simple.

| Unfortunately bash doesn't implement some of them, and has a lot of
| non-standard extensions that really just cause portability issues.

(Continue reading)

Alex Goncharov | 1 Jan 2011 15:57
Picon

Re: mksh import

,--- I/Alex (Sat, 01 Jan 2011 08:41:08 -0500) ----*
| ,--- David Laight (Sat, 1 Jan 2011 11:52:43 +0000) ----*
| | If you want to write scripts that are portable between machines, you
| | need to ensure that you only use the 'posix' features.
| 
| No: I only need to have the same version of the interpreter (Bash)
| installed on all machines.  Which is simple.
| 
| As I said, I don't care if a standards body approved a Bash feature
| -- I care about being able to do a job.  Bash being not portable would
| make me think about using a different shell but because it is more
| portable than anything else, why should I care about a "standard"?
| It works; it works well.
| 
| | If you really want portability you need to restrict yourself to the
| | 'traditional' bourne shell (eg /bin/sh on solaris).

[ On the perceived portability of /bin/sh ]

On AIX, /bin/sh is /bin/ksh, by default, and everywhere I've seen
(Bourne shell is /bin/bsh):

----------------------------------------
uname -svr; man bsh | head -n 10; for o in ksh bsh; do cmp /bin/sh
/bin/$o && echo "sh == $o" || echo "sh != $o"; done
=>
AIX 3 5

                                                            Commands Reference, Volume 1, a - c

(Continue reading)

Joerg Sonnenberger | 1 Jan 2011 16:47
Picon

Re: mksh import

On Sat, Jan 01, 2011 at 08:41:08AM -0500, Alex Goncharov wrote:
> | Unfortunately bash doesn't implement some of them, and has a lot of
> | non-standard extensions that really just cause portability issues.
> 
> As I said, I don't care if a standards body approved a Bash feature
> -- I care about being able to do a job.  Bash being not portable would
> make me think about using a different shell but because it is more
> portable than anything else, why should I care about a "standard"?
> It works; it works well.

Bash is not even compatible with the rest of the GNU shell tools. How
else would you explain that the test builtin and /usr/bin/test from
coretuils are not compatible?

Joerg

der Mouse | 1 Jan 2011 18:26

Re: mksh import

> Let me try to offer you a user's perspective.

> [...]

> And, any day of the week, I could say, "Thank God, Bash exists!.."

Great.

What does that have to do with what goes into base?

There are tons of tools I have and use (and mostly wrote) which lead me
to say similar things[%].  But I'm not trying to get any of them into
base; I draw a distinction between "this is useful to me" and "this is
worth imposing on every install of NetBSD, including ones not involving
humans indirecting with it directly".  I'm not even sure I think base's
sh should have line editing support, though the benefit to humans doing
broken-system repair may be worth it.

[%] blt.  buffer.  calc.  catblock.  char-to-code/code-to-char.
    compare.  copytolog.  count.  cvtbase.  filetimes.  findproc.
    halign.  kal.  ls.  mcgrep.  mcsh.  nc.  rdiff.  skipcat.
    wait-for.  That's just the ones I can name offhand that find
    frequent applicability no matter what I'm doing; there are many
    more for more specialized use (such as the netpbm suite when
    working with images).

I've tried to use bare NetBSD, ie, without at least a handful of the
most useful of those tools.  It's...painful.  I'm quite crippled until
I get a reasonable subset of them in place.

(Continue reading)

Alex Goncharov | 1 Jan 2011 18:29
Picon

Re: mksh import

,--- You/Joerg (Sat, 1 Jan 2011 16:47:07 +0100) ----*
| Bash is not even compatible with the rest of the GNU shell tools. How
| else would you explain that the test builtin and /usr/bin/test from
| coretuils are not compatible?

Why is this important?

I am on a FreeBSD system now:

------------------------------
type -a test
=>
test is a shell builtin
test is /bin/test
------------------------------

I don't even have the coretuils port installed.

When would I need to use /bin/test, or /usr/bin/test,
/usr/local/bin/test or /usr/pkg/bin/test?  The builtin is found and
used by 'bash' unless I do something special (I don't even remember
what, because I never had to use a utility instead of a Bash builtin.)

-- Alex -- alex-goncharov <at> comcast.net --

Alex Goncharov | 1 Jan 2011 18:37
Picon

Re: mksh import

,--- You/der (Sat, 1 Jan 2011 12:26:39 -0500 (EST)) ----*
| > Let me try to offer you a user's perspective.
|
| > And, any day of the week, I could say, "Thank God, Bash exists!.."
| 
| What does that have to do with what goes into base?

Did I try to suggest that?  I was replying to your comment on the
"modern":

,--- You/der Mouse (Fri, 31 Dec 2010 19:43:26 -0500 (EST)) ----*
|
| > I think that it would be good to have at least one modern shell in
| > our base, [...]
| 
| What meaning of "modern" are you using here?
| 
| Lots of people use "modern" this way, but I've seen almost as many
| meanings as I have people using it, so I no longer trust myself to
| understand what anyone using it actually means.
|
`--------------------------------------------------------*

| There are tons of tools I have and use (and mostly wrote) which lead me
| to say similar things[%].  But I'm not trying to get any of them into
| base; I draw a distinction between "this is useful to me" and "this is
| worth imposing on every install of NetBSD, including ones not involving
| humans indirecting with it directly".  I'm not even sure I think base's
| sh should have line editing support, though the benefit to humans doing
| broken-system repair may be worth it.
(Continue reading)


Gmane