'#!/usr/bin/env bash -e' vs 'set -e'.

[hongy...@gmail.com]

I try to set the following option for my bash script:

-e Exit immediately if a command exits with a non-zero status.

For this purpose, I try the following two methods:

1. Use the following shebang line:

#!/usr/bin/env bash -e

2. Use the separate set command:

#!/usr/bin/env bash
set -e

It seems the latter will do the trick while the former can't.

Any hints for this issue will highly be appreciated.

Regards,
HY

[Keith Thompson]

It would have been useful to say more than "can't" to describe how the
first option failed.

The "#!" syntax typically permits only a single argument. On my system,
it tries to invoke "/usr/bin/env" with the single argument "bash -e".
Since there is no command named "bash -e", it fails with the error
message you should have shown us.

This is a unfortunate limitation of the #!/usr/bin/env hack. Using
"#!/bin/bash -e" should work (assuming that's where your bash is
installed).

I've discussed the advantages and disadvantages of the "#!/usr/bin/env"
hack here: https://unix.stackexchange.com/a/29620/10454

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

[hongy...@gmail.com]

On Thursday, December 24, 2020 at 12:51:28 PM UTC+8, Keith Thompson wrote:
> "hongy...@gmail.com" <hongy...@gmail.com> writes:
> > I try to set the following option for my bash script:
> >
> > -e Exit immediately if a command exits with a non-zero status.
> >
> > For this purpose, I try the following two methods:
> >
> > 1. Use the following shebang line:
> >
> > #!/usr/bin/env bash -e
> >
> > 2. Use the separate set command:
> >
> > #!/usr/bin/env bash
> > set -e
> >
> > It seems the latter will do the trick while the former can't.
> >
> > Any hints for this issue will highly be appreciated.
> It would have been useful to say more than "can't" to describe how the
> first option failed.
>
> The "#!" syntax typically permits only a single argument. On my system,
> it tries to invoke "/usr/bin/env" with the single argument "bash -e".
> Since there is no command named "bash -e", it fails with the error
> message you should have shown us.
>
> This is a unfortunate limitation of the #!/usr/bin/env hack. Using
> "#!/bin/bash -e" should work (assuming that's where your bash is
> installed).
>
> I've discussed the advantages and disadvantages of the "#!/usr/bin/env"
> hack here: https://unix.stackexchange.com/a/29620/10454

It looks like a very complicated thing using shabang line based solutions. So, the most simple workaround is use the separted "set -e" command for this purpose.

[Chris Elvidge]

Before you rely on 'set -e', read Greg Wooledge's wiki article:
https://mywiki.wooledge.org/BashFAQ/105?highlight=%28errexit%29

--
Chris Elvidge
England

[Kenny McCormack]

In article <rs1phf$9ou$1...@dont-email.me>,
Chris Elvidge <ch...@mshome.net> wrote:
...

>Before you rely on 'set -e', read Greg Wooledge's wiki article:
>https://mywiki.wooledge.org/BashFAQ/105?highlight=%28errexit%29

And then ignore it, because it is nonsense...

Well written, and worth the read, but ultimately nonsense.

--
I'm building a wall.

[hongy...@gmail.com]

What do you think of the following method cited in the above mentioned article:

http://redsymbol.net/articles/unofficial-bash-strict-mode/
Use Bash Strict Mode (Unless You Love Debugging)

Let's start with the punchline. Your bash scripts will be more robust, reliable and maintainable if you start them like this:

#!/bin/bash
set -euo pipefail
IFS=$'\n\t'


Regards,
HY

[Chris Elvidge]

What does this do?

#!/bin/bash
set -euo pipefail
IFS=$'\n\t'

i=0
let i++
printf 'i is %d\n' $i
#((i++))
#((i++)) && printf 'i is %d\n' $i
((i++)) || printf 'i is %d\n' $i
printf "Got to the end i=%d\n" $i


Move the comment(s) (#) around to see different results
Reliable? Robust? Maintainable?


--
Chris Elvidge
England

[hongy...@gmail.com]

Thanks for your carefully prepared example. But I still can't figure out what's best practice for the issue in question.

[Janis Papanagnou]

[ Hongyi took the next step of using this newsgroup for personal
support only, by removing the newsgroup from the addressee list.
Noticed too late and reposted here. ]

On 24.12.2020 16:38, hongy...@gmail.com wrote:

>>>> In article <rs1phf$9ou$1...@dont-email.me>, Chris Elvidge wrote:
>>>>> Before you rely on 'set -e', read Greg Wooledge's wiki article:
>>>>> https://mywiki.wooledge.org/BashFAQ/105?highlight=%28errexit%29

Interesting. Didn't know that someone wrote something up about it.
(It's a pity that [in this article] it's only focussing on bash.)

> Thanks for your carefully prepared example. But I still can't figure
> out what's best practice for the issue in question.

I don't recall to have ever used 'set -e', mainly because it handles
errors *undifferentiated*, and that is thus also the implicit answer
to your question; instead of 'set -e' use explicit '|| exit N' and
'&& exit N' where you want errors detected and the program aborted,
and catch the errors and handle them (using 'if cmd; then ...; fi')
where you want the program to continue or abort in well-defined ways.

Janis

[Janis Papanagnou]

On 24.12.2020 17:19, Janis Papanagnou wrote:
> [ Hongyi took the next step of using this newsgroup for personal
> support only, by removing the newsgroup from the addressee list.
> Noticed too late and reposted here. ]

This is not true, I did him wrong. Sorry Hyongi!
(Completely my fault after a reinstalled newsreader.)

JAnis

[Kaz Kylheku]

On 2020-12-24, hongy...@gmail.com <hongy...@gmail.com> wrote:
> I try to set the following option for my bash script:
>
> -e Exit immediately if a command exits with a non-zero status.
>
> For this purpose, I try the following two methods:
>
> 1. Use the following shebang line:
>
> #!/usr/bin/env bash -e

Note this invocation will only work on platforms where the hash bang
mechanism can pass two (or more) arguments from the hash bang line to
the interpreter. Portable hash bang scripts can assume only one
parameter. For that reason, some implementations of env provide a way
to encode multiple arguments in a single argument.

--
TXR Programming Language: http://nongnu.org/txr

[Chris Elvidge]

On 24/12/2020 04:19 pm, Janis Papanagnou wrote:
>>>>> In article<rs1phf$9ou$1...@dont-email.me>, Chris Elvidge wrote:
>>>>>> Before you rely on 'set -e', read Greg Wooledge's wiki article:
>>>>>> https://mywiki.wooledge.org/BashFAQ/105?highlight=%28errexit%29
> Interesting. Didn't know that someone wrote something up about it.
> (It's a pity that [in this article] it's only focussing on bash.)
>

Greg seems to be part of the team that writes Bash


--
Chris Elvidge
England

[Kaz Kylheku]

Do you mean is that it's actually informative, but the opinion rants
included in it are nonsense? That is true, but it's also misinformative.

The author doesn't grasp that termination status can be successful or
failed. Further, that a failed status can be due to normal or abnormal
termination.

set -e catches all situations where the utility failed abnormally, or
terminated normally with a failed indication.

The rules for suppressing -e in conditionals are in no way convoluted.

The conditional is already reacting to the termination status, so it
would be completely nonsensical for -e to overrule that.

The set -e mechanism is almost exactly the same thing like, in a
language with exceptions, establishing a disposition for unhandled
exceptions.

# if command fails, this is a "handled exception":

if command arg ; then ... ; else ... fi

# if command fails here, this is an "unhandled exception"
command arg

set -e says that the "unhandled exception" is not ignored, but
terminates the program.

We just substitute "untested termination status" for "unhandled
exception" and all is clear.

The wiki article is completely wrong and misinformative in the following
way.

Commands in a pipeline other than the last one being immune to set -e
makes sense when we consider that, to the shell, the entire pipeline is
actually a "job" with a single termination status. If a component of a
pipeline fails which is not the last component, the component to the
right of it is supposed to detect that.

Given he pipeline A | B | C. you cannot use an if statement to test
whether B succeeded, right?

if A | B | C ; then ...

means "test the termination status of the pipeline" ....

Therefore, that same termination semantics is also exactly what set -e
also tests!

I don't see the complication here; only necessary consistency.

Bash has a pipefail option to alter the pipeline job error detecting
behavior. The man page clearly documents that "[i]f pipefail is
enabled, the pipeline's return status is the value of the last
(rightmost) command to exit with a non-zero status, or zero if all
commands exit successfully."

Note how there is no mention of "set -e" here. The pipefail option
establishes how the termination status of a pipeline job is calculated,
not how "set -e" treats pipelines.

[Janis Papanagnou]

In that light the comment on the referenced page (follow the "Answers"
link): "However, this behavior changed in bash 4.1. Exercise 2 works
only in bash 4.0 and earlier! In bash 4.1, [...]" sounds a bit strange.

Given the behavioral difference even between bash versions it would be
interesting to have a more global view about how other shells behave.

Janis

[Randal L. Schwartz]

>>>>> "Kenny" == Kenny McCormack <gaz...@shell.xmission.com> writes:

Kenny> And then ignore it, because it is nonsense...

Kenny> Well written, and worth the read, but ultimately nonsense.

Part of why, once I discovered Perl, I have lost most of my shell-coding
brain and thankfully so.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/Dart consulting, Technical writing, Comedy, etc. etc.
Still trying to think of something clever for the fourth line of this .sig

[hongy...@gmail.com]

On Friday, December 25, 2020 at 6:03:14 AM UTC+8, Randal L. Schwartz wrote:
> >>>>> "Kenny" == Kenny McCormack <gaz...@shell.xmission.com> writes:
>
> Kenny> And then ignore it, because it is nonsense...
>
> Kenny> Well written, and worth the read, but ultimately nonsense.
>
> Part of why, once I discovered Perl, I have lost most of my shell-coding
> brain and thankfully so.

IMO, Perl has quite weird grammar and variable rules. Do you really think it is so wonderful and fascinating?

[Javier]

Kaz Kylheku <563-36...@kylheku.com> wrote:
> set -e says that the "unhandled exception" is not ignored, but
> terminates the program.

In addition to terminating immediately it is possible trigger a
command or function on error with

trap my_function ERR

As in this example

https://github.com/pottmi/stringent.sh/blob/master/stringent.sh

[Randal L. Schwartz]

>>>>> "hongy" == hongy @gmail com <hongy...@gmail.com> writes:

hongy> IMO, Perl has quite weird grammar and variable rules. Do you
hongy> really think it is so wonderful and fascinating?

You must not know who I am. :)

[hongy...@gmail.com]

On Friday, December 25, 2020 at 12:03:25 PM UTC+8, Randal L. Schwartz wrote:
> >>>>> "hongy" == hongy @gmail com <hongy...@gmail.com> writes:
>
> hongy> IMO, Perl has quite weird grammar and variable rules. Do you
> hongy> really think it is so wonderful and fascinating?
>
> You must not know who I am. :)

To be frank, I'm a newbie of Perl but often hear about its well-known regexp powered character processing capabilities. Are you really Randal L. Schwartz as described on this Wikipedia page: <https://en.wikipedia.org/wiki/Randal_L._Schwartz>?

[Randal L. Schwartz]

>>>>> "hongy" == hongy @gmail com <hongy...@gmail.com> writes:

hongy> To be frank, I'm a newbie of Perl but often hear about its
hongy> well-known regexp powered character processing capabilities. Are
hongy> you really Randal L. Schwartz as described on this Wikipedia
hongy> page: <https://en.wikipedia.org/wiki/Randal_L._Schwartz>?

Yes, that'd be me.

[Dan Espen]

Of course he is.

But your comments reveal something.
Here you are criticizing Perl and then declaring yourself a newbie.
Maybe you should gain some real knowledge before you make a fool of yourself.

Perl beats shell to death.
All these ridiculous questions you keep asking about shell
show how badly shell stacks up against a real scripting
language.

Really, if you're trying to anything serious, shell is absolutely the
wrong way to go.

Back when I worked, I pulled many small projects out of the crapper
by throwing away all the shell/awk/sed crap and recoding in Perl.

Today I'd recommend Python, (I'd be interested to hear how Randall
feels about that). Shell is good for a few lines. After that
you need something with more power.

--
Dan Espen

[Spiros Bousbouras]

On Fri, 25 Dec 2020 13:34:36 -0500
Dan Espen <dan1...@gmail.com> wrote:

> "hongy...@gmail.com" <hongy...@gmail.com> writes:

> All these ridiculous questions you keep asking about shell
> show how badly shell stacks up against a real scripting
> language.

"Real scripting language" is a meaningless phrase. And I don't think Hongyi's
questions allow any conclusions to be drawn about the power of the shell(s).

> Really, if you're trying to anything serious, shell is absolutely the
> wrong way to go.

Depends on what one is trying to do.

> Today I'd recommend Python, (I'd be interested to hear how Randall
> feels about that).

I'd rather not have a Perl vs Python flamewar on this group.

> Shell is good for a few lines. After that
> you need something with more power.

I've written plenty of stuff with more than a few lines with shell and they
have been totally reliable over many years. But above a certain size I would
tend to prefer Korn over Bash.

--
After all is said and done, a lot more will have been said than done.
Unknown

[Spiros Bousbouras]

On Thu, 24 Dec 2020 14:46:01 +0000
Chris Elvidge <ch...@mshome.net> wrote:
> What does this do?
>
> #!/bin/bash
> set -euo pipefail
> IFS=$'\n\t'
> i=0
> let i++
> printf 'i is %d\n' $i
> #((i++))
> #((i++)) && printf 'i is %d\n' $i
> ((i++)) || printf 'i is %d\n' $i
> printf "Got to the end i=%d\n" $i

Off the top of my head I can't say but it's obfuscated code so why should I
consult man pages and find out ? To the extent I can guess at the point the
code is trying to illustrate , the lesson is that if you use set -e and
you want to increase the value of a variable by 1 , the way which won't hold
any surprises is

i=$(( $i + 1 ))

And if you want to test whether a variable is 0 you do
if [ $i -eq 0 ] ; then

In almost all my shell scripts above a certain size , I've used set -e and
it has worked fine. I've had a couple of surprises but these were related to
other aspects of Bash I would consider poorly designed hence I prefer Korn
for anything above some level of complexity (and I still use set -e ).

> Move the comment(s) (#) around to see different results
> Reliable? Robust? Maintainable?

Probably no to all your questions but if you explain in words what the code
is trying to do , I'm sure that I could write it in a way which is all 3.

--
Pornography should be renamed "socially distanced sex".

[Dan Espen]

Spiros Bousbouras <spi...@gmail.com> writes:

> On Fri, 25 Dec 2020 13:34:36 -0500
> Dan Espen <dan1...@gmail.com> wrote:
>> "hongy...@gmail.com" <hongy...@gmail.com> writes:
>
>> All these ridiculous questions you keep asking about shell
>> show how badly shell stacks up against a real scripting
>> language.
>
> "Real scripting language" is a meaningless phrase. And I don't think Hongyi's
> questions allow any conclusions to be drawn about the power of the shell(s).
>
>> Really, if you're trying to anything serious, shell is absolutely the
>> wrong way to go.
>
> Depends on what one is trying to do.
>
>> Today I'd recommend Python, (I'd be interested to hear how Randall
>> feels about that).
>
> I'd rather not have a Perl vs Python flamewar on this group.

I'm just interested in Randall's opinion of Python.
You start a flame war if you want. I won't help.

>> Shell is good for a few lines. After that
>> you need something with more power.
>
> I've written plenty of stuff with more than a few lines with shell and they
> have been totally reliable over many years. But above a certain size I would
> tend to prefer Korn over Bash.

Funny, the stuff I had to rescue was ksh.

A real scripting language can do the entire job, I thought I made that
clear. You don't need awk, sed, and bunch of other languages to get the
job done.

--
Dan Espen

[Kaz Kylheku]

On 2020-12-25, Dan Espen <dan1...@gmail.com> wrote:
> Perl beats shell to death.

That describes the implemenation concept of Perl even more than it
describes competition with the shell.

[Dan Espen]

Kaz Kylheku <563-36...@kylheku.com> writes:

> On 2020-12-25, Dan Espen <dan1...@gmail.com> wrote:
>> Perl beats shell to death.
>
> That describes the implemenation concept of Perl even more than it
> describes competition with the shell.

Not sure I follow but I'm LOL!

--
Dan Espen

[Janis Papanagnou]

On 25.12.2020 20:32, Spiros Bousbouras wrote:
> On Fri, 25 Dec 2020 13:34:36 -0500 Dan Espen <dan1...@gmail.com> wrote:
>

>> [ with reference to perl or python ]

>> Shell is good for a few lines. After that you need something with more power.

In my experience it's usually not the number of lines that suggests
to choose one or another language. There are many ways to control
code complexity (and even memory demands or execution speed).

There's no problem writing arbitrary long shell code; use functions,
local variables, external programs and libraries. For bash users that
require speedy execution my first suggestion would *not* be to switch
from bash to perl, but from bash to ksh; because most bash features
are already existing in (even originating from) ksh and there's thus
[almost] no migration necessary. And if that is not sufficient I'd
suggest to switch to a fast compiled language (like C++) not to perl
or python (but preferences differ, of course).

But other requirements may come into ones way; shell is POSIX standard.
You wrote: "throwing away all the shell/awk/sed crap"
As opposed to perl or python, all this "crap" is reliable standard and
it is since decades.

> I've written plenty of stuff with more than a few lines with shell and they
> have been totally reliable over many years. But above a certain size I would
> tend to prefer Korn over Bash.

I see no advantage to use Bash for small shell programs, I just use Ksh.

The IMO biggest problem with shells is the lack of data structures.
But the application domain of shells is typically differing from other
(compiled) languages. Ksh has a couple extensions in this direction,
but then you are leaving the area of POSIX standard and portability.

Janis

[Janis Papanagnou]

On 25.12.2020 21:09, Dan Espen wrote:
>
> A real scripting language can do the entire job, I thought I made that
> clear. You don't need awk, sed, and bunch of other languages to get the
> job done.

In restricted standard environments I used to have to work on in many
companies I needed these standard tools to get my job done.

Janis

[Spiros Bousbouras]

On Fri, 25 Dec 2020 22:03:18 +0100
Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> On 25.12.2020 20:32, Spiros Bousbouras wrote:

> > I've written plenty of stuff with more than a few lines with shell and they
> > have been totally reliable over many years. But above a certain size I would
> > tend to prefer Korn over Bash.
>
> I see no advantage to use Bash for small shell programs, I just use Ksh.

I'm just more used to Bash because I use it for the command line which I find
more convenient than Korn (but I haven't tried hard to make my Korn command
line experience the same as with Bash). Many small shell "scripts" I write
are actually functions so it makes sense to write them in the same shell I
use for the command line.

[Dan Espen]

Yes, the projects I was on did a lot of shell stuff because we needed
to be sure the customers had the same tools available. This was late
90s, early 00. We struggled with shell and eventually came to realize
that every one of our customers had Perl. So, we stopped fighting shell
and the quality of our products increased a lot.

I think what bothered me the most was all our code fragmented into
dozens of separate files, some shell, some awk, even lex. As the application
got more complex it was increasingly hard to understand and work on.

--
Dan Espen

[Randal L. Schwartz]

>>>>> "Dan" == Dan Espen <dan1...@gmail.com> writes:

>>
>> I'd rather not have a Perl vs Python flamewar on this group.

Dan> I'm just interested in Randall's opinion of Python.
Dan> You start a flame war if you want. I won't help.

It's a good thing you're asking about this mythical "Randall" person and
not me. :)

[Dan Espen]

mer...@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Dan" == Dan Espen <dan1...@gmail.com> writes:
>
>>>
>>> I'd rather not have a Perl vs Python flamewar on this group.
>
> Dan> I'm just interested in Randall's opinion of Python.
> Dan> You start a flame war if you want. I won't help.
>
> It's a good thing you're asking about this mythical "Randall" person and
> not me. :)

Sorry.

There are several variant spellings of the English given name; these
include Randal, Randel, Randell, Randle, and Rendell.



--
Dan Espen

[Kenny McCormack]

In article <rs6033$f71$1...@dont-email.me>,

Dan Espen <dan1...@gmail.com> wrote:
>mer...@stonehenge.com (Randal L. Schwartz) writes:
>
>>>>>>> "Dan" == Dan Espen <dan1...@gmail.com> writes:
>>
>>>>
>>>> I'd rather not have a Perl vs Python flamewar on this group.
>>
>> Dan> I'm just interested in Randall's opinion of Python.
>> Dan> You start a flame war if you want. I won't help.
>>
>> It's a good thing you're asking about this mythical "Randall" person and
>> not me. :)
>
>Sorry.
>

> There are several ...

I think you missed the joke.

One can infer what RLS thinks about Python from the text posted above.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/CLCtopics

[Dan Espen]

gaz...@shell.xmission.com (Kenny McCormack) writes:

> In article <rs6033$f71$1...@dont-email.me>,
> Dan Espen <dan1...@gmail.com> wrote:
>>mer...@stonehenge.com (Randal L. Schwartz) writes:
>>
>>>>>>>> "Dan" == Dan Espen <dan1...@gmail.com> writes:
>>>
>>>>>
>>>>> I'd rather not have a Perl vs Python flamewar on this group.
>>>
>>> Dan> I'm just interested in Randall's opinion of Python.
>>> Dan> You start a flame war if you want. I won't help.
>>>
>>> It's a good thing you're asking about this mythical "Randall" person and
>>> not me. :)
>>
>>Sorry.
>>
>> There are several ...
>
> I think you missed the joke.
>
> One can infer what RLS thinks about Python from the text posted above.

I guess I'm still missing the joke.
Since he put Randall in quotes and he actually spells his name
differently isn't "mythical" in reference to that misspelling?

--
Dan Espen

[Dan Espen]

Okay, since he's 100% devoted to Perl, it's good I asked someone else.
I guess he has no actual opinions about Python at all other than it's
not Perl.

Oh well.

I liked Perl a lot but I needed to use QT and at the time
there was Python support but not Perl support. I think I still like the actual
Perl language better than Python. But Python has a huge following and
therefore lots of packages. In my case more of the ones I needed.

--
Dan Espen

[Kaz Kylheku]

On 2020-12-25, Randal L. Schwartz <mer...@stonehenge.com> wrote:
>>>>>> "Dan" == Dan Espen <dan1...@gmail.com> writes:
>
>>>
>>> I'd rather not have a Perl vs Python flamewar on this group.
>
>Dan> I'm just interested in Randall's opinion of Python.
>Dan> You start a flame war if you want. I won't help.
>
> It's a good thing you're asking about this mythical "Randall" person and
> not me. :)

If it's Randall Hyde, then of course nothing but assembly language.

[Janis Papanagnou]

On 25.12.2020 23:10, Spiros Bousbouras wrote:
> On Fri, 25 Dec 2020 22:03:18 +0100
> Janis Papanagnou <janis_pa...@hotmail.com> wrote:
>>
>> I see no advantage to use Bash for small shell programs, I just use Ksh.
>
> I'm just more used to Bash because I use it for the command line which I find
> more convenient than Korn (but I haven't tried hard to make my Korn command
> line experience the same as with Bash).

Frankly, all I can tell about line editing modes in these two shells is
that ksh has a couple different options how it behaves interactively (I
use just one) and that whenever I am using bash I tend to switch shell
(to ksh) because I don't like the behavior of bash's [default] command
line behavior. Personally I also prefer the power of vi editing, and I
use thus ksh's vi-mode (with [one of] ksh's tab-completions). The truth
is also that ksh has a long-existing unfixed bug with tab-completion in
context of tilde expressions that occasionally pops in; but I live with
it because of the other advantages I see with this mode.

> Many small shell "scripts" I write
> are actually functions so it makes sense to write them in the same shell I
> use for the command line.

I also use the same shell interactively as I use for programming. (But
I also understand very well that some folks prefer tcsh for interactive
use and one of the Bourne-family shells for programming.)

Janis

[Randal L. Schwartz]

>>>>> "Dan" == Dan Espen <dan1...@gmail.com> writes:

Dan> Okay, since he's 100% devoted to Perl, it's good I asked someone else.
Dan> I guess he has no actual opinions about Python at all other than it's
Dan> not Perl.

Absolutely lot. My passion (and hope to turn in to a profession) these
days is Dart and Flutter. (Yes, I fell in love with strong and sound
typing, especially the opportunity for editor assistance while coding,
which I now miss when I go back to Perl.)

Dan> I liked Perl a lot but I needed to use QT and at the time there was
Dan> Python support but not Perl support. I think I still like the
Dan> actual Perl language better than Python. But Python has a huge
Dan> following and therefore lots of packages. In my case more of the
Dan> ones I needed.

The CPAN is still richly populated, but yes, doesn't have everything one
might need. Surprisingly, after only a few years, the Pub
(Dart/Flutter's equivalent) is indeed quite populated.

Just another Dart hacker,

[Curt]

On 2020-12-25, Dan Espen <dan1...@gmail.com> wrote:
> Kaz Kylheku <563-36...@kylheku.com> writes:
>
>> On 2020-12-25, Dan Espen <dan1...@gmail.com> wrote:
>>> Perl beats shell to death.
>>
>> That describes the implemenation concept of Perl even more than it
>> describes competition with the shell.
>
> Not sure I follow but I'm LOL!
>

That's what it intended to do more than what it actually did.

[Randal L. Schwartz]

>>>>> "Randal" == Randal L Schwartz <mer...@stonehenge.com> writes:

Randal> Absolutely lot.

s/lot/not/. Ugh, happens before caffiene.

[Dan Espen]

mer...@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Randal" == Randal L Schwartz <mer...@stonehenge.com> writes:
>
> Randal> Absolutely lot.
>
> s/lot/not/. Ugh, happens before caffiene.

The lot/not was clear enough.
But something looked odd with the rest of your sentence.
I before E, except after C. Except when it's not.

--
Dan Espen

[Dan Espen]

mer...@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Dan" == Dan Espen <dan1...@gmail.com> writes:
>
> Dan> Okay, since he's 100% devoted to Perl, it's good I asked someone else.
> Dan> I guess he has no actual opinions about Python at all other than it's
> Dan> not Perl.
>
> Absolutely lot. My passion (and hope to turn in to a profession) these
> days is Dart and Flutter. (Yes, I fell in love with strong and sound
> typing, especially the opportunity for editor assistance while coding,
> which I now miss when I go back to Perl.)
>
> Dan> I liked Perl a lot but I needed to use QT and at the time there was
> Dan> Python support but not Perl support. I think I still like the
> Dan> actual Perl language better than Python. But Python has a huge
> Dan> following and therefore lots of packages. In my case more of the
> Dan> ones I needed.
>
> The CPAN is still richly populated, but yes, doesn't have everything one
> might need. Surprisingly, after only a few years, the Pub
> (Dart/Flutter's equivalent) is indeed quite populated.
>
> Just another Dart hacker,

Hmm, something else for me to look into. Thanks.

Wasn't there supposed to be a flame war?

--
Dan Espen

[Randal L. Schwartz]

>>>>> "Dan" == Dan Espen <dan1...@gmail.com> writes:

>> s/lot/not/. Ugh, happens before caffiene.

Dan> The lot/not was clear enough.
Dan> But something looked odd with the rest of your sentence.
Dan> I before E, except after C. Except when it's not.

Yeah, that's one of those words I wait for the autocorrect to fix. No
autocorrect in a GNU Emacs window here, unless I invoke ISpell on it.

[Dan Espen]

mer...@stonehenge.com (Randal L. Schwartz) writes:

>>>>>> "Dan" == Dan Espen <dan1...@gmail.com> writes:
>
>>> s/lot/not/. Ugh, happens before caffiene.
>
> Dan> The lot/not was clear enough.
> Dan> But something looked odd with the rest of your sentence.
> Dan> I before E, except after C. Except when it's not.
>
> Yeah, that's one of those words I wait for the autocorrect to fix. No
> autocorrect in a GNU Emacs window here, unless I invoke ISpell on it.

Well, I spotted it just because it looked a little weird then I asked
Emacs (GNUS) to spell check it.

I don't use auto-correct but I get squiggly lines when I misspell.
From my .gnus.el:

(add-hook 'message-mode-hook (lambda () (flyspell-mode 1)))

--
Dan Espen

[hongy...@gmail.com]

Here is a script written in Bash up to 10000 lines:

https://github.com/mviereck/x11docker/blob/master/x11docker

[Spiros Bousbouras]

On Sat, 26 Dec 2020 16:21:23 +0100
Janis Papanagnou <janis_pa...@hotmail.com> wrote:
> On 25.12.2020 23:10, Spiros Bousbouras wrote:
> > I'm just more used to Bash because I use it for the command line which I find
> > more convenient than Korn (but I haven't tried hard to make my Korn command
> > line experience the same as with Bash).
>
> Frankly, all I can tell about line editing modes in these two shells is
> that ksh has a couple different options how it behaves interactively (I
> use just one) and that whenever I am using bash I tend to switch shell
> (to ksh) because I don't like the behavior of bash's [default] command
> line behavior. Personally I also prefer the power of vi editing, and I
> use thus ksh's vi-mode (with [one of] ksh's tab-completions).

I don't use tab completions so that's not the issue I have with the Korn
command line editing (CLE). I use vi(m) mode too but the issues I have with
Korn are the following :

1. If you are at the prompt and you press <UP arrow> to go to the latest
item in history you are in normal mode at the beginning of the line. With
Bash you are in insert mode at the end of the line. Based on some common
patterns of CLE of mine , I prefer the BASH behaviour.

2. With Korn if you are in insert mode and you press <LEFT (or RIGHT) arrow>
it takes you to normal mode. With Bash you stay in insert mode.

3. With Korn , if you are in insert mode and press <DELETE> you cannot delete
to the left of the point in the command line where you entered insert mode ,
with Bash you can. I note that Korn's behaviour is the traditional vi one
but I prefer the Bash behaviour. In vim itself , you can change the
behaviour based on the value of the backspace option.

I actually had a (not thorough) look in the Korn man page to see if there is
some setting which allows you to change these things and I couldn't find one.

--
If this is its last appearance in the chemical literature, I won't be surprised.
There are no conceivable uses for it - well, other than blowing up Raman
spectrometers, which is a small market - and the number of research groups who would
even contemplate a resynthesis can probably be counted on one well-armored hand.
https://blogs.sciencemag.org/pipeline/archives/2013/01/09/things_i_wont_work_with_azidoazide_azides_more_or_less

[Janis Papanagnou]

On 29.12.2020 02:10, Spiros Bousbouras wrote:
> I don't use tab completions so that's not the issue I have with the Korn
> command line editing (CLE). I use vi(m) mode too but the issues I have with
> Korn are the following :
>
> 1. If you are at the prompt and you press <UP arrow> to go to the latest
> item in history you are in normal mode at the beginning of the line. With
> Bash you are in insert mode at the end of the line. Based on some common
> patterns of CLE of mine , I prefer the BASH behaviour.

Interesting. This exactly is what drives me mad in bash. The patterns
I usually apply start with the command. Or with the options which are
also closer to the command than to the arguments. (But of course, if
I'm moving on the line I'm also quickly at the point where I want to
be, using W, w, f, $, etc., and with multi-line commands using v.)
I also do a lot word-wise where I want to be at the beginning of the
words (or line). At the end of the line I typically only append (but
that can be done from anywhere in the line by typing A ), and getting
to the end of any word I use E or e. The other purpose, deleting from
the end backwards I consider too cumbersome (especially if many args
are involved); a simple C or d$ or dW or d3W is much faster and less
error prone IME. (It also supports my thinking "from left to right".)

In Bash (using vi mode) I have permanently the feeling that operations
are much more clumsy and start making operations character-wise instead
of item-wise.

> 2. With Korn if you are in insert mode and you press <LEFT (or RIGHT) arrow>
> it takes you to normal mode. With Bash you stay in insert mode.

For me it's similar to using vim; normally I am in command mode, and
I do almost everything (but inserts of texts) in this mode. In shell
it's exactly the same; I prefer doing most stuff in command (normal)
mode, so that's exactly what I want from Kornshell.

The difference seems to be that I rarely use [character-wise] cursor
movement and [character-wise] deletes/backspace. I usually move in
larger quantities than characters (word-wise or move-to-target), and
erasures or changes are also done on larger quantities (words, parts
of words, to end (or start) of line, etc.; I use the vi commands as
they are designed to be efficiently used.

> 3. With Korn , if you are in insert mode and press <DELETE> you cannot delete
> to the left of the point in the command line where you entered insert mode ,
> with Bash you can.

True. I suppose it depends whether one wants only newly inserted text
cleared or not. Personally that never bothered me because I am editing
most things in command mode (it's more powerful) and want just the new
parts entered be corrected on typos. In case I want to correct parts of
the old text and enter new text I start at the place where the edits
should be done and then all new text is subject to possible corrections.

> I note that Korn's behaviour is the traditional vi one
> but I prefer the Bash behaviour. In vim itself , you can change the
> behaviour based on the value of the backspace option.

In vim there's even a mode (forgot its name) that's oriented on simple
cursor oriented editing practices (which can be found in primitive GUI
editors - some may call it "user-friendly"). I consider it a hindrance
to efficient editing, though.

> I actually had a (not thorough) look in the Korn man page to see if there is
> some setting which allows you to change these things and I couldn't find one.

I think that it's not possible to change it the way you like. But since
it works for me I also haven't examined the possibilities or variants.

Janis

[Janis Papanagnou]

On 27.12.2020 00:16, hongy...@gmail.com wrote:
>
> Here is a script written in Bash up to 10000 lines:
>
> https://github.com/mviereck/x11docker/blob/master/x11docker

I'm not sure what that post shall demonstrate. - Maybe that 64 kB
memory isn't sufficient nowadays?

Janis