This suggestion follows the current discussion about using special
characters as data, which shows just how horrible DCL is when it
comes to using special characters as data in a command line.

How difficult would it be to alter DCL to add modern style quoting
of reserved characters ?

In bash, escaping a special character is simple - you just add a
backslash in front of the special character, so ' would become \'
instead. I think that's vastly better and cleaner than how it is
done in DCL.

What do you think ?

On another unrelated question, does anyone here use brace expansion
in bash and if so, how useful do you find it ? For example, typing:

simon{1,2}.txt

as a filename argument would create a command line which replaced the
above with:

simon1.txt simon2.txt

Would anyone find that useful for DCL ? I find it _very_ useful in bash.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/19/2022 1:33 PM, Simon Clubley wrote:
> This suggestion follows the current discussion about using special
> characters as data, which shows just how horrible DCL is when it
> comes to using special characters as data in a command line.
>
> How difficult would it be to alter DCL to add modern style quoting
> of reserved characters ?
>
> In bash, escaping a special character is simple - you just add a
> backslash in front of the special character, so ' would become \'
> instead. I think that's vastly better and cleaner than how it is
> done in DCL.
>
> What do you think ?

DCL is DCL and bash is bash.

Generally making \ an escape character in DCL will break some
existing code.

And I am not too keen on SET DCL/ESC=ENABLE.

Why not just say that those that need something more advanced than
DCL use just that.

They can get bash via GNV.

They can also use Python, Perl etc..

> On another unrelated question, does anyone here use brace expansion
> in bash and if so, how useful do you find it ? For example, typing:
>
> simon{1,2}.txt
>
> as a filename argument would create a command line which replaced the
> above with:
>
> simon1.txt simon2.txt
>
> Would anyone find that useful for DCL ? I find it _very_ useful in bash.

It would be tricky with DCL because DCL is different from the typical
*nix shell. The *nix shell does the globbing before activating the
program. DCL just pass on the argument to the program.

Arne

In article <ss9lil$764$2@dont-email.me>, Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> This suggestion follows the current discussion about using special
> characters as data, which shows just how horrible DCL is when it
> comes to using special characters as data in a command line.
>
> How difficult would it be to alter DCL to add modern style quoting
> of reserved characters ?
>
> In bash, escaping a special character is simple - you just add a
> backslash in front of the special character, so ' would become \'
> instead. I think that's vastly better and cleaner than how it is
> done in DCL.

Interestingly, I was searching a .tex file. \<anything> are TeX control
codes. :-|

On 1/19/22 9:12 PM, Phillip Helbig (undress to reply) wrote:
> In article <ss9lil$764$2@dont-email.me>, Simon Clubley
> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
....
>> In bash, escaping a special character is simple - you just add a
>> backslash in front of the special character, so ' would become \'
>> instead. I think that's vastly better and cleaner than how it is
>> done in DCL.
>
> Interestingly, I was searching a .tex file. \<anything> are TeX control
> codes. :-|
>
On VMS:
$ ty helloworld.tex
\documentclass[12pt]{article}
\begin{document}
Hello world!
$Hello world!$ %math mode
\end{document}
$ grep "\\end" helloworld.tex
\end{document}
$ Same command works in bash, although one would prefer
$ grep '\\end' helloworld.tex

Den 2022-01-19 kl. 19:49, skrev Arne Vajhøj:
> On 1/19/2022 1:33 PM, Simon Clubley wrote:
>> This suggestion follows the current discussion about using special
>> characters as data, which shows just how horrible DCL is when it
>> comes to using special characters as data in a command line.
>>
>> How difficult would it be to alter DCL to add modern style quoting
>> of reserved characters ?
>>
>> In bash, escaping a special character is simple - you just add a
>> backslash in front of the special character, so ' would become \'
>> instead. I think that's vastly better and cleaner than how it is
>> done in DCL.
>>
>> What do you think ?
>
> DCL is DCL and bash is bash.
>
> Generally making \ an escape character in DCL will break some
> existing code.
>
> And I am not too keen on SET DCL/ESC=ENABLE.
>
> Why not just say that those that need something more advanced than
> DCL use just that.
>
> They can get bash via GNV.
>
> They can also use Python, Perl etc..
>
>> On another unrelated question, does anyone here use brace expansion
>> in bash and if so, how useful do you find it ? For example, typing:
>>
>>     simon{1,2}.txt
>>
>> as a filename argument would create a command line which replaced the
>> above with:
>>
>>     simon1.txt simon2.txt
>>
>> Would anyone find that useful for DCL ? I find it _very_ useful in bash.
>
> It would be tricky with DCL because DCL is different from the typical
> *nix shell. The *nix shell does the globbing before activating the
> program. DCL just pass on the argument to the program.
>
> Arne
>
>

My take is that VSI should focus on those things that really make
a difference for the *majority* uf the VMS users, and in particular
for the owners of the companies where these systems are used.

In our environment (and I guess that is valid for most current VMS
environments), out of the approx 200 "users" there are probably 3-4
that actually "use" DCL. So what group should we focus on?

How many of the end-users of system running VMS realy cares about DCL?

Why should we focus on things that such a minority of the VMS
users really "use" in their daily work?

I'd say that any additions to DCL that you can think of, does
nothing to the general acceptance of VMS as a platform.

If the shell is that important for a platforms success or failure,
Linux whould have been dead by now. A more user-unfriendly interface
is hard do find.

In article <61e85d4e$0$700$14726298@news.sunsite.dk>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= <arne@vajhoej.dk> writes:
>On 1/19/2022 1:33 PM, Simon Clubley wrote:
>> This suggestion follows the current discussion about using special
>> characters as data, which shows just how horrible DCL is when it
>> comes to using special characters as data in a command line.
>>
>> How difficult would it be to alter DCL to add modern style quoting
>> of reserved characters ?
>>
>> In bash, escaping a special character is simple - you just add a
>> backslash in front of the special character, so ' would become \'
>> instead. I think that's vastly better and cleaner than how it is
>> done in DCL.
>>
>> What do you think ?
>
>DCL is DCL and bash is bash.
>
>Generally making \ an escape character in DCL will break some
>existing code.
>
>And I am not too keen on SET DCL/ESC=ENABLE.
>
>Why not just say that those that need something more advanced than
>DCL use just that.

But, but, but, Simon has a hair up his ass for DCL and if those people
were to do what you've suggested, his daily DCL diatribes would mostly
be just the ravings of a unix lunatic -- not that they aren't already
just that.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 1/19/2022 5:26 PM, Jan-Erik Söderholm wrote:
> Den 2022-01-19 kl. 19:49, skrev Arne Vajhøj:
>> On 1/19/2022 1:33 PM, Simon Clubley wrote:
>>> This suggestion follows the current discussion about using special
>>> characters as data, which shows just how horrible DCL is when it
>>> comes to using special characters as data in a command line.
>>>
>>> How difficult would it be to alter DCL to add modern style quoting
>>> of reserved characters ?
>>>
>>> In bash, escaping a special character is simple - you just add a
>>> backslash in front of the special character, so ' would become \'
>>> instead. I think that's vastly better and cleaner than how it is
>>> done in DCL.
>>>
>>> What do you think ?
>>
>> DCL is DCL and bash is bash.
>>
>> Generally making \ an escape character in DCL will break some
>> existing code.
>>
>> And I am not too keen on SET DCL/ESC=ENABLE.
>>
>> Why not just say that those that need something more advanced than
>> DCL use just that.
>>
>> They can get bash via GNV.
>>
>> They can also use Python, Perl etc..

> My take is that VSI should focus on those things that really make
> a difference for the *majority* uf the VMS users, and in particular
> for the owners of the companies where these systems are used.
>
> In our environment (and I guess that is valid for most current VMS
> environments), out of the approx 200 "users" there are probably 3-4
> that actually "use" DCL. So what group should we focus on?
>
> How many of the end-users of system running VMS realy cares about DCL?
>
> Why should we focus on things that such a minority of the VMS
> users really "use" in their daily work?
>
> I'd say that any additions to DCL that you can think of, does
> nothing to the general acceptance of VMS as a platform.

Very few VMS users work at the DCL prompt today.

But I think a lot of VMS "users" are benefitting from
scripts running on VMS.

So good script capabilities does matter.

But I don't think huge updates to DCL is the way forward
for scripting.

Existing DCL needs to continue to work as it has for 10-20-30-40 years.

New stuff can be written in something else.

Arne

On 20/01/2022 02:14, Arne Vajhøj wrote:
> On 1/19/2022 5:26 PM, Jan-Erik Söderholm wrote:
>> Den 2022-01-19 kl. 19:49, skrev Arne Vajhøj:
>>> On 1/19/2022 1:33 PM, Simon Clubley wrote:
>>>> This suggestion follows the current discussion about using special
>>>> characters as data, which shows just how horrible DCL is when it
>>>> comes to using special characters as data in a command line.
>>>>
>>>> How difficult would it be to alter DCL to add modern style quoting
>>>> of reserved characters ?
>>>>
>>>> In bash, escaping a special character is simple - you just add a
>>>> backslash in front of the special character, so ' would become \'
>>>> instead. I think that's vastly better and cleaner than how it is
>>>> done in DCL.
>>>>
>>>> What do you think ?
>>>
>>> DCL is DCL and bash is bash.
>>>
>>> Generally making \ an escape character in DCL will break some
>>> existing code.
>>>
>>> And I am not too keen on SET DCL/ESC=ENABLE.
>>>
>>> Why not just say that those that need something more advanced than
>>> DCL use just that.
>>>
>>> They can get bash via GNV.
>>>
>>> They can also use Python, Perl etc..
>
>> My take is that VSI should focus on those things that really make
>> a difference for the *majority* uf the VMS users, and in particular
>> for the owners of the companies where these systems are used.
>>
>> In our environment (and I guess that is valid for most current VMS
>> environments), out of the approx 200 "users" there are probably 3-4
>> that actually "use" DCL. So what group should we focus on?
>>
>> How many of the end-users of system running VMS realy cares about DCL?
>>
>> Why should we focus on things that such a minority of the VMS
>> users really "use" in their daily work?
>>
>> I'd say that any additions to DCL that you can think of, does
>> nothing to the general acceptance of VMS as a platform.
>
> Very few VMS users work at the DCL prompt today.
>
> But I think a lot of VMS "users" are benefitting from
> scripts running on VMS.
>
> So good script capabilities does matter.
>
> But I don't think huge updates to DCL is the way forward
> for scripting.
>
> Existing DCL needs to continue to work as it has for 10-20-30-40 years.
>
> New stuff can be written in something else.
>
> Arne

It is not as if it is difficult to install various 'nix utilities. I
have quite a few, although I probably only use a a few of them - grep
being one of them

Chris

--
Chris

In article <ss9ujo$14m3$1@gioia.aioe.org>, hb <end.of@inter.net> writes:

> On 1/19/22 9:12 PM, Phillip Helbig (undress to reply) wrote:
> > In article <ss9lil$764$2@dont-email.me>, Simon Clubley
> > <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
> ....
> >> In bash, escaping a special character is simple - you just add a
> >> backslash in front of the special character, so ' would become \'
> >> instead. I think that's vastly better and cleaner than how it is
> >> done in DCL.
> >
> > Interestingly, I was searching a .tex file. \<anything> are TeX control
> > codes. :-|
> >
> On VMS:
> $ ty helloworld.tex
> \documentclass[12pt]{article}
> \begin{document}
> Hello world!
> $Hello world!$ %math mode
> \end{document}
> $ grep "\\end" helloworld.tex
> \end{document}
> $
> Same command works in bash, although one would prefer
> $ grep '\\end' helloworld.tex

Consider the TeX command \". OK, to search for it I need to escape the
backslash, thus search for \\". But then " is part of what I'm
searching for, so using that as a delimiter is also tricky. The DCL
solution has the advantage that it is pretty obvious what it does.

Note that \\ is also a valid TeX command (which means "start a new line
here". So to search for that I would search for \\\\?

Den 2022-01-20 kl. 09:28, skrev Phillip Helbig (undress to reply):
> In article <ss9ujo$14m3$1@gioia.aioe.org>, hb <end.of@inter.net> writes:
>
>> On 1/19/22 9:12 PM, Phillip Helbig (undress to reply) wrote:
>>> In article <ss9lil$764$2@dont-email.me>, Simon Clubley
>>> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>> ....
>>>> In bash, escaping a special character is simple - you just add a
>>>> backslash in front of the special character, so ' would become \'
>>>> instead. I think that's vastly better and cleaner than how it is
>>>> done in DCL.
>>>
>>> Interestingly, I was searching a .tex file. \<anything> are TeX control
>>> codes. :-|
>>>
>> On VMS:
>> $ ty helloworld.tex
>> \documentclass[12pt]{article}
>> \begin{document}
>> Hello world!
>> $Hello world!$ %math mode
>> \end{document}
>> $ grep "\\end" helloworld.tex
>> \end{document}
>> $
>> Same command works in bash, although one would prefer
>> $ grep '\\end' helloworld.tex
>
> Consider the TeX command \". OK, to search for it I need to escape the
> backslash, thus search for \\". But then " is part of what I'm
> searching for, so using that as a delimiter is also tricky.

If " is escapable, it would be '$ grep "\\\"" helloworld.tex'.

Or if that line is processed by DCL, maybe '$ grep "\\""" helloworld.tex'.
The usual double double-quote to get one double-quote.

> The DCL
> solution has the advantage that it is pretty obvious what it does.
>
> Note that \\ is also a valid TeX command (which means "start a new line
> here". So to search for that I would search for \\\\?
>

Yes, two (2) escaped backslashes looks fine.

>

On 1/20/22 10:35, Jan-Erik Söderholm wrote:
> Den 2022-01-20 kl. 09:28, skrev Phillip Helbig (undress to reply):
....
>> Consider the TeX command \".  OK, to search for it I need to escape the
>> backslash, thus search for \\".  But then " is part of what I'm
>> searching for, so using that as a delimiter is also tricky.
>
> If " is escapable, it would be '$ grep "\\\"" helloworld.tex'.
>
> Or if that line is processed by DCL, maybe '$ grep "\\""" helloworld.tex'.
> The usual double double-quote to get one double-quote.
>
>
>> The DCL
>> solution has the advantage that it is pretty obvious what it does.
>>
>> Note that \\ is also a valid TeX command (which means "start a new line
>> here".  So to search for that I would search for \\\\?
>>
>
> Yes, two (2) escaped backslashes looks fine.

Real code, real examples?

On VMS, from DCL
$ ty morehellos.tex
\documentclass[12pt]{article}
\begin{document}
Hello w\"orld!
Hello\\world!
"Hello world!"
\end{document}
$ $ grep "\\""" morehellos.tex
Hello w\"orld!
$ $ grep "\\\\" morehellos.tex
Hello\\world!
$ $ grep """" morehellos.tex
Hello w\"orld!
"Hello world!"
$

From a bash you would probably use a single quote as a string
delimiter. Which means you do not need to escape anything for bash
within the string except the string delimiter, which is not searched,
here. Anything in the string is a regular expression. That itself
requires escaping its escape character - same as from DCL.

$ grep '\\"' morehellos.tex
Hello w\"orld!
$ $ grep '\\\\' morehellos.tex
Hello\\world!
$ $ grep '"' morehellos.tex
Hello w\"orld!
"Hello world!"
$

From bash, if you really want to use double quotes as a string
delimiter, you need to escape the bash special characters, as they are
interpreted in that string.

$ grep "\\\\\"" morehellos.tex
Hello w\"orld!
$ $ grep "\\\\\\\\" morehellos.tex
Hello\\world!
$ grep "\"" morehellos.tex
Hello w\"orld!
"Hello world!"
$

On Thu, 20 Jan 2022 11:59:59 +0100, hb wrote:

> From bash, if you really want to use double quotes as a string
> delimiter, you need to escape the bash special characters, as they are
> interpreted in that string.
>
> $ grep "\\\\\"" morehellos.tex Hello w\"orld!
> $
> $ grep "\\\\\\\\" morehellos.tex Hello\\world!
> $
> grep "\"" morehellos.tex Hello w\"orld!
> "Hello world!"

Or just use single quotes to surrouhd the search string. bash won't touch
anything inside those.

$ grep '"' whateverfile

--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

On 1/19/2022 9:37 PM, Chris Townley wrote:
> On 20/01/2022 02:14, Arne Vajhøj wrote:
>> On 1/19/2022 5:26 PM, Jan-Erik Söderholm wrote:
>>> Den 2022-01-19 kl. 19:49, skrev Arne Vajhøj:
>>>> On 1/19/2022 1:33 PM, Simon Clubley wrote:
>>>>> This suggestion follows the current discussion about using special
>>>>> characters as data, which shows just how horrible DCL is when it
>>>>> comes to using special characters as data in a command line.
>>>>>
>>>>> How difficult would it be to alter DCL to add modern style quoting
>>>>> of reserved characters ?
>>>>>
>>>>> In bash, escaping a special character is simple - you just add a
>>>>> backslash in front of the special character, so ' would become \'
>>>>> instead. I think that's vastly better and cleaner than how it is
>>>>> done in DCL.
>>>>>
>>>>> What do you think ?
>>>>
>>>> DCL is DCL and bash is bash.
>>>>
>>>> Generally making \ an escape character in DCL will break some
>>>> existing code.
>>>>
>>>> And I am not too keen on SET DCL/ESC=ENABLE.
>>>>
>>>> Why not just say that those that need something more advanced than
>>>> DCL use just that.
>>>>
>>>> They can get bash via GNV.
>>>>
>>>> They can also use Python, Perl etc..
>>
>>> My take is that VSI should focus on those things that really make
>>> a difference for the *majority* uf the VMS users, and in particular
>>> for the owners of the companies where these systems are used.
>>>
>>> In our environment (and I guess that is valid for most current VMS
>>> environments), out of the approx 200 "users" there are probably 3-4
>>> that actually "use" DCL. So what group should we focus on?
>>>
>>> How many of the end-users of system running VMS realy cares about DCL?
>>>
>>> Why should we focus on things that such a minority of the VMS
>>> users really "use" in their daily work?
>>>
>>> I'd say that any additions to DCL that you can think of, does
>>> nothing to the general acceptance of VMS as a platform.
>>
>> Very few VMS users work at the DCL prompt today.
>>
>> But I think a lot of VMS "users" are benefitting from
>> scripts running on VMS.
>>
>> So good script capabilities does matter.
>>
>> But I don't think huge updates to DCL is the way forward
>> for scripting.
>>
>> Existing DCL needs to continue to work as it has for 10-20-30-40 years.
>>
>> New stuff can be written in something else.
>
> It is not as if it is difficult to install various 'nix utilities. I
> have quite a few, although I probably only use a a few of them - grep
> being one of them

*nix or general - bash and tools are obvious *nix but Perl
and Python are not *nix specific.

DCL is a good interactive command language and not as good
a scripting language.

If DEC 35 years ago had decided to enhance DCL to make
it a great scripting language then it would have made sense:
- DEC had money
- bash/Perl/Python did not exist yet
- smaller DCL code base and the people that wrote the DCL were
still around

But the world are different today:
- VSI is a small company that need to prioritize resources
- bash/Perl/Python exist, are maintained by other and all
the VMS world need to do is to make sure they also run on VMS
- larger DCL code base and some places there may no longer be
the skills available to update if breaking changes are introduced

Arne

On 1/20/22 9:19 AM, Arne Vajhøj wrote:
> On 1/19/2022 9:37 PM, Chris Townley wrote:
>> On 20/01/2022 02:14, Arne Vajhøj wrote:
>>> On 1/19/2022 5:26 PM, Jan-Erik Söderholm wrote:
>>>> Den 2022-01-19 kl. 19:49, skrev Arne Vajhøj:
>>>>> On 1/19/2022 1:33 PM, Simon Clubley wrote:
>>>>>> This suggestion follows the current discussion about using special
>>>>>> characters as data, which shows just how horrible DCL is when it
>>>>>> comes to using special characters as data in a command line.
>>>>>>
>>>>>> How difficult would it be to alter DCL to add modern style quoting
>>>>>> of reserved characters ?
>>>>>>
>>>>>> In bash, escaping a special character is simple - you just add a
>>>>>> backslash in front of the special character, so ' would become \'
>>>>>> instead. I think that's vastly better and cleaner than how it is
>>>>>> done in DCL.
>>>>>>
>>>>>> What do you think ?
>>>>>
>>>>> DCL is DCL and bash is bash.
>>>>>
>>>>> Generally making \ an escape character in DCL will break some
>>>>> existing code.
>>>>>
>>>>> And I am not too keen on SET DCL/ESC=ENABLE.
>>>>>
>>>>> Why not just say that those that need something more advanced than
>>>>> DCL use just that.
>>>>>
>>>>> They can get bash via GNV.
>>>>>
>>>>> They can also use Python, Perl etc..
>>>
>>>> My take is that VSI should focus on those things that really make
>>>> a difference for the *majority* uf the VMS users, and in particular
>>>> for the owners of the companies where these systems are used.
>>>>
>>>> In our environment (and I guess that is valid for most current VMS
>>>> environments), out of the approx 200 "users" there are probably 3-4
>>>> that actually "use" DCL. So what group should we focus on?
>>>>
>>>> How many of the end-users of system running VMS realy cares about DCL?
>>>>
>>>> Why should we focus on things that such a minority of the VMS
>>>> users really "use" in their daily work?
>>>>
>>>> I'd say that any additions to DCL that you can think of, does
>>>> nothing to the general acceptance of VMS as a platform.
>>>
>>> Very few VMS users work at the DCL prompt today.
>>>
>>> But I think a lot of VMS "users" are benefitting from
>>> scripts running on VMS.
>>>
>>> So good script capabilities does matter.
>>>
>>> But I don't think huge updates to DCL is the way forward
>>> for scripting.
>>>
>>> Existing DCL needs to continue to work as it has for 10-20-30-40 years.
>>>
>>> New stuff can be written in something else.
>>
>> It is not as if it is difficult to install various 'nix utilities. I
>> have quite a few, although I probably only use a a few of them - grep
>> being one of them
>
> *nix or general - bash and tools are obvious *nix

bash is Linux, not Unix. Yet another case of NIH because there
were already shells available with all the features and abilities
of bash.

> but Perl
> and Python are not *nix specific.

Both were originally developed in the Unix environment. Use in any
other environment is an afterthought.

>
> DCL is a good interactive command language and not as good
> a scripting language.
>
> If DEC 35 years ago had decided to enhance DCL to make
> it a great scripting language then it would have made sense:
> - DEC had money
> - bash/Perl/Python did not exist yet

Maybe not bash, but other shells which were ideal for both
interactive use and scripting were.

> - smaller DCL code base and the people that wrote the DCL were
>   still around
>
> But the world are different today:
> - VSI is a small company that need to prioritize resources
> - bash/Perl/Python exist, are maintained by other and all
>   the VMS world need to do is to make sure they also run on VMS
> - larger DCL code base and some places there may no longer be
>   the skills available to update if breaking changes are introduced
>

bill

On 1/20/2022 10:25 AM, Bill Gunshannon wrote:
> On 1/20/22 9:19 AM, Arne Vajhøj wrote:
>> On 1/19/2022 9:37 PM, Chris Townley wrote:
>>> On 20/01/2022 02:14, Arne Vajhøj wrote:
>>>> Very few VMS users work at the DCL prompt today.
>>>>
>>>> But I think a lot of VMS "users" are benefitting from
>>>> scripts running on VMS.
>>>>
>>>> So good script capabilities does matter.
>>>>
>>>> But I don't think huge updates to DCL is the way forward
>>>> for scripting.
>>>>
>>>> Existing DCL needs to continue to work as it has for 10-20-30-40 years.
>>>>
>>>> New stuff can be written in something else.
>>>
>>> It is not as if it is difficult to install various 'nix utilities. I
>>> have quite a few, although I probably only use a a few of them - grep
>>> being one of them
>>
>> *nix or general - bash and tools are obvious *nix
>
> bash is Linux, not Unix.

Bash was developed on Unix (first version of bash came out
2 years before the first version of Linux). It became
popular on Linux and was later adopted by various Unixes.

I think *nix is a good term to describe it.

>   Yet another case of NIH because there
> were already shells available with all the features and abilities
> of bash.

People seems to prefer bash over the other available shells.

>
>>                                                     but Perl
>> and Python are not *nix specific.
>
> Both were originally developed in the Unix environment.  Use in any
> other environment is an afterthought.

They were developed on Unix but I don't think calling usage on
other platforms an afterthought is proper description.

When Guido Rossum released the first public version of Python he wrote:

<quote>
It runs on most modern versions of UNIX, on the Mac, and
I wouldn't be surprised if it ran on MS-DOS unchanged. I developed it
mostly on an SGI IRIS workstation (using IRIX 3.1 and 3.2) and on the
Mac, but have tested it also on SunOS (4.1) and BSD 4.3 (tahoe).
</quote>

so he did test on Mac from day 1 (and Mac at that time was not *nix).

When Larry Wall released the first public version of Perl the build
configuration included:

<quote>
/* EUNICE:
* This symbol, if defined, indicates that the program is being compiled
* under the EUNICE package under VMS. The program will need to handle
* things like files that don't go away the first time you unlink them,
* due to version numbering. It will also need to compensate for lack
* of a respectable link() command.
*/
/* VMS:
* This symbol, if defined, indicates that the program is running under
* VMS. It is currently only set in conjunction with the EUNICE symbol.
*/
</quote>

so definitely Unix centric but VMS aware.

>> DCL is a good interactive command language and not as good
>> a scripting language.
>>
>> If DEC 35 years ago had decided to enhance DCL to make
>> it a great scripting language then it would have made sense:
>> - DEC had money
>> - bash/Perl/Python did not exist yet
>
> Maybe not bash, but other shells which were ideal for both
> interactive use and scripting were.

sh, csh, ksh etc. was around.

But no more ideal than very few use them today.

Arne

On 1/20/22 11:26 AM, Arne Vajhøj wrote:
> On 1/20/2022 10:25 AM, Bill Gunshannon wrote:
>> On 1/20/22 9:19 AM, Arne Vajhøj wrote:
>>> On 1/19/2022 9:37 PM, Chris Townley wrote:
>>>> On 20/01/2022 02:14, Arne Vajhøj wrote:
>>>>> Very few VMS users work at the DCL prompt today.
>>>>>
>>>>> But I think a lot of VMS "users" are benefitting from
>>>>> scripts running on VMS.
>>>>>
>>>>> So good script capabilities does matter.
>>>>>
>>>>> But I don't think huge updates to DCL is the way forward
>>>>> for scripting.
>>>>>
>>>>> Existing DCL needs to continue to work as it has for 10-20-30-40
>>>>> years.
>>>>>
>>>>> New stuff can be written in something else.
>>>>
>>>> It is not as if it is difficult to install various 'nix utilities. I
>>>> have quite a few, although I probably only use a a few of them -
>>>> grep being one of them
>>>
>>> *nix or general - bash and tools are obvious *nix
>>
>> bash is Linux, not Unix.
>
> Bash was developed on Unix (first version of bash came out
> 2 years before the first version of Linux). It became
> popular on Linux and was later adopted by various Unixes.
>
> I think *nix is a good term to describe it.

Sadly, I don't think any Linux users (or even most Linux
developers) have ever read any of the books like "Software
Tools" or "The Unix Programming Environment". It may look
somewhat like Unix, but it is lacking in the underlying
paradigm.

>
>>                           Yet another case of NIH because there
>> were already shells available with all the features and abilities
>> of bash.
>
> People seems to prefer bash over the other available shells.

Some do. Mostly Linux users.

>
>>
>>>                                                     but Perl
>>> and Python are not *nix specific.
>>
>> Both were originally developed in the Unix environment.  Use in any
>> other environment is an afterthought.
>
> They were developed on Unix but I don't think calling usage on
> other platforms an afterthought is proper description.
>
> When Guido Rossum released the first public version of Python he wrote:
>
> <quote>
> It runs on most modern versions of UNIX, on the Mac, and
> I wouldn't be surprised if it ran on MS-DOS unchanged.  I developed it
> mostly on an SGI IRIS workstation (using IRIX 3.1 and 3.2) and on the
> Mac, but have tested it also on SunOS (4.1) and BSD 4.3 (tahoe).
> </quote>
>
> so he did test on Mac from day 1 (and Mac at that time was not *nix).
>
> When Larry Wall released the first public version of Perl the build
> configuration included:
>
> <quote>
> /* EUNICE:
>  *    This symbol, if defined, indicates that the program is being
> compiled
>  *    under the EUNICE package under VMS.  The program will need to handle
>  *    things like files that don't go away the first time you unlink them,
>  *    due to version numbering.  It will also need to compensate for lack
>  *    of a respectable link() command.
>  */
> /* VMS:
>  *    This symbol, if defined, indicates that the program is running under
>  *    VMS.  It is currently only set in conjunction with the EUNICE
> symbol.
>  */
> </quote>
>
> so definitely Unix centric but VMS aware.

EUNICE? That's Unix running on top of VMS. :-)
Can it be compiled and run if you set the VMS flag?

>
>>> DCL is a good interactive command language and not as good
>>> a scripting language.
>>>
>>> If DEC 35 years ago had decided to enhance DCL to make
>>> it a great scripting language then it would have made sense:
>>> - DEC had money
>>> - bash/Perl/Python did not exist yet
>>
>> Maybe not bash, but other shells which were ideal for both
>> interactive use and scripting were.
>
> sh, csh, ksh etc. was around.
>
> But no more ideal than very few use them today.

Funny, that. NetBSD, OpenBSD and FreeBSD don't ship with bash
installed and not offered as one of the default shells in the
/etc/shells file. I don't even use bash on Linux. I haven't
used Solaris in quite some time but the last time I did it
was the same. I have used Unix since Version7 and have never
used a version of Unix that shipped with bash. Only Linux
does that.

bill

On 20/01/2022 17:37, Bill Gunshannon wrote:
> On 1/20/22 11:26 AM, Arne Vajhøj wrote:
>> On 1/20/2022 10:25 AM, Bill Gunshannon wrote:
>>> On 1/20/22 9:19 AM, Arne Vajhøj wrote:
>>>> On 1/19/2022 9:37 PM, Chris Townley wrote:
>>>>> On 20/01/2022 02:14, Arne Vajhøj wrote:
>>>>>> Very few VMS users work at the DCL prompt today.
>>>>>>
>>>>>> But I think a lot of VMS "users" are benefitting from
>>>>>> scripts running on VMS.
>>>>>>
>>>>>> So good script capabilities does matter.
>>>>>>
>>>>>> But I don't think huge updates to DCL is the way forward
>>>>>> for scripting.
>>>>>>
>>>>>> Existing DCL needs to continue to work as it has for 10-20-30-40
>>>>>> years.
>>>>>>
>>>>>> New stuff can be written in something else.
>>>>>
>>>>> It is not as if it is difficult to install various 'nix utilities.
>>>>> I have quite a few, although I probably only use a a few of them -
>>>>> grep being one of them
>>>>
>>>> *nix or general - bash and tools are obvious *nix
>>>
>>> bash is Linux, not Unix.
>>
>> Bash was developed on Unix (first version of bash came out
>> 2 years before the first version of Linux). It became
>> popular on Linux and was later adopted by various Unixes.
>>
>> I think *nix is a good term to describe it.
>
> Sadly, I don't think any Linux users (or even most Linux
> developers) have ever read any of the books like "Software
> Tools" or "The Unix Programming Environment".  It may look
> somewhat like Unix, but it is lacking in the underlying
> paradigm.
>
>>
>>>                           Yet another case of NIH because there
>>> were already shells available with all the features and abilities
>>> of bash.
>>
>> People seems to prefer bash over the other available shells.
>
> Some do.  Mostly Linux users.
>
>>
>>>
>>>>                                                     but Perl
>>>> and Python are not *nix specific.
>>>
>>> Both were originally developed in the Unix environment.  Use in any
>>> other environment is an afterthought.
>>
>> They were developed on Unix but I don't think calling usage on
>> other platforms an afterthought is proper description.
>>
>> When Guido Rossum released the first public version of Python he wrote:
>>
>> <quote>
>> It runs on most modern versions of UNIX, on the Mac, and
>> I wouldn't be surprised if it ran on MS-DOS unchanged.  I developed it
>> mostly on an SGI IRIS workstation (using IRIX 3.1 and 3.2) and on the
>> Mac, but have tested it also on SunOS (4.1) and BSD 4.3 (tahoe).
>> </quote>
>>
>> so he did test on Mac from day 1 (and Mac at that time was not *nix).
>>
>> When Larry Wall released the first public version of Perl the build
>> configuration included:
>>
>> <quote>
>> /* EUNICE:
>>   *    This symbol, if defined, indicates that the program is being
>> compiled
>>   *    under the EUNICE package under VMS.  The program will need to
>> handle
>>   *    things like files that don't go away the first time you unlink
>> them,
>>   *    due to version numbering.  It will also need to compensate for
>> lack
>>   *    of a respectable link() command.
>>   */
>> /* VMS:
>>   *    This symbol, if defined, indicates that the program is running
>> under
>>   *    VMS.  It is currently only set in conjunction with the EUNICE
>> symbol.
>>   */
>> </quote>
>>
>> so definitely Unix centric but VMS aware.
>
> EUNICE?  That's Unix running on top of VMS. :-)
> Can it be compiled and run if you set the VMS flag?
>
>>
>>>> DCL is a good interactive command language and not as good
>>>> a scripting language.
>>>>
>>>> If DEC 35 years ago had decided to enhance DCL to make
>>>> it a great scripting language then it would have made sense:
>>>> - DEC had money
>>>> - bash/Perl/Python did not exist yet
>>>
>>> Maybe not bash, but other shells which were ideal for both
>>> interactive use and scripting were.
>>
>> sh, csh, ksh etc. was around.
>>
>> But no more ideal than very few use them today.
>
> Funny, that.  NetBSD, OpenBSD and FreeBSD don't ship with bash
> installed and not offered as one of the default shells in the
> /etc/shells file.  I don't even use bash on Linux.  I haven't
> used Solaris in quite some time but the last time I did it
> was the same. I have used Unix since Version7 and have never
> used a version of Unix that shipped with bash.  Only Linux
> does that.
>
> bill
>

I do use bash on linux, but still use ksh for scripting - I started
mainstream Unix on tru64. I did use ksh as my shell some time ago, but
bash is really a superset of the bourn and korn shells, so fair for
interactive use.

--
Chris

On 2022-01-19, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>
> If the shell is that important for a platforms success or failure,
> Linux whould have been dead by now. A more user-unfriendly interface
> is hard do find.
>

What about JCL ? :-)

Bash is cryptic, but it is also powerful.

It would be nice to have readability with the power however...

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-01-20, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>
> Funny, that. NetBSD, OpenBSD and FreeBSD don't ship with bash
> installed and not offered as one of the default shells in the
> /etc/shells file. I don't even use bash on Linux. I haven't
> used Solaris in quite some time but the last time I did it
> was the same. I have used Unix since Version7 and have never
> used a version of Unix that shipped with bash. Only Linux
> does that.
>

Having recently briefly used the default shell in both NetBSD and
OpenBSD, I can tell you that I would strongly prefer bash as the
default shell on a Unix system instead. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/20/22 1:31 PM, Simon Clubley wrote:
> On 2022-01-19, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>>
>> If the shell is that important for a platforms success or failure,
>> Linux whould have been dead by now. A more user-unfriendly interface
>> is hard do find.
>>
>
> What about JCL ? :-)
>
> Bash is cryptic, but it is also powerful.

What's cryptic about bash?

>
> It would be nice to have readability with the power however...
>

shells are a lot more readable than PHP or PERL.

bill

On 1/20/2022 12:37 PM, Bill Gunshannon wrote:
> On 1/20/22 11:26 AM, Arne Vajhøj wrote:
>> On 1/20/2022 10:25 AM, Bill Gunshannon wrote:
>>> On 1/20/22 9:19 AM, Arne Vajhøj wrote:
>>>> On 1/19/2022 9:37 PM, Chris Townley wrote:
>>>>> On 20/01/2022 02:14, Arne Vajhøj wrote:
>>>>>> Very few VMS users work at the DCL prompt today.
>>>>>>
>>>>>> But I think a lot of VMS "users" are benefitting from
>>>>>> scripts running on VMS.
>>>>>>
>>>>>> So good script capabilities does matter.
>>>>>>
>>>>>> But I don't think huge updates to DCL is the way forward
>>>>>> for scripting.
>>>>>>
>>>>>> Existing DCL needs to continue to work as it has for 10-20-30-40
>>>>>> years.
>>>>>>
>>>>>> New stuff can be written in something else.
>>>>>
>>>>> It is not as if it is difficult to install various 'nix utilities.
>>>>> I have quite a few, although I probably only use a a few of them -
>>>>> grep being one of them
>>>>
>>>> *nix or general - bash and tools are obvious *nix
>>>
>>> bash is Linux, not Unix.
>>
>> Bash was developed on Unix (first version of bash came out
>> 2 years before the first version of Linux). It became
>> popular on Linux and was later adopted by various Unixes.
>>
>> I think *nix is a good term to describe it.
>
> Sadly, I don't think any Linux users (or even most Linux
> developers) have ever read any of the books like "Software
> Tools" or "The Unix Programming Environment".  It may look
> somewhat like Unix, but it is lacking in the underlying
> paradigm.

The world has evolved. Different problems and different solutions.

>>>>                                                     but Perl
>>>> and Python are not *nix specific.
>>>
>>> Both were originally developed in the Unix environment.  Use in any
>>> other environment is an afterthought.
>>
>> They were developed on Unix but I don't think calling usage on
>> other platforms an afterthought is proper description.
>>
>> When Guido Rossum released the first public version of Python he wrote:
>>
>> <quote>
>> It runs on most modern versions of UNIX, on the Mac, and
>> I wouldn't be surprised if it ran on MS-DOS unchanged.  I developed it
>> mostly on an SGI IRIS workstation (using IRIX 3.1 and 3.2) and on the
>> Mac, but have tested it also on SunOS (4.1) and BSD 4.3 (tahoe).
>> </quote>
>>
>> so he did test on Mac from day 1 (and Mac at that time was not *nix).
>>
>> When Larry Wall released the first public version of Perl the build
>> configuration included:
>>
>> <quote>
>> /* EUNICE:
>>   *    This symbol, if defined, indicates that the program is being
>> compiled
>>   *    under the EUNICE package under VMS.  The program will need to
>> handle
>>   *    things like files that don't go away the first time you unlink
>> them,
>>   *    due to version numbering.  It will also need to compensate for
>> lack
>>   *    of a respectable link() command.
>>   */
>> /* VMS:
>>   *    This symbol, if defined, indicates that the program is running
>> under
>>   *    VMS.  It is currently only set in conjunction with the EUNICE
>> symbol.
>>   */
>> </quote>
>>
>> so definitely Unix centric but VMS aware.
>
> EUNICE?  That's Unix running on top of VMS. :-)
> Can it be compiled and run if you set the VMS flag?

I believe Eunice was a shell and library similar to
later Posix for VMS or Cygwin on Windows.

And my guess will be that it required Eunice to build
but could run from DCL.

>>>> DCL is a good interactive command language and not as good
>>>> a scripting language.
>>>>
>>>> If DEC 35 years ago had decided to enhance DCL to make
>>>> it a great scripting language then it would have made sense:
>>>> - DEC had money
>>>> - bash/Perl/Python did not exist yet
>>>
>>> Maybe not bash, but other shells which were ideal for both
>>> interactive use and scripting were.
>>
>> sh, csh, ksh etc. was around.
>>
>> But no more ideal than very few use them today.
>
> Funny, that.  NetBSD, OpenBSD and FreeBSD don't ship with bash
> installed and not offered as one of the default shells in the
> /etc/shells file.  I don't even use bash on Linux.  I haven't
> used Solaris in quite some time but the last time I did it
> was the same. I have used Unix since Version7 and have never
> used a version of Unix that shipped with bash.  Only Linux
> does that.

I believe that bash is default shell on Linux and Solaris,
default install on macOS, an extra install on AIX and
*BSD and an extra install on VMS (GNV) & Windows (Cygwin)
today.

Arne

On 2022-01-20, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
> On 1/20/22 1:31 PM, Simon Clubley wrote:
>> On 2022-01-19, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>>>
>>> If the shell is that important for a platforms success or failure,
>>> Linux whould have been dead by now. A more user-unfriendly interface
>>> is hard do find.
>>>
>>
>> What about JCL ? :-)
>>
>> Bash is cryptic, but it is also powerful.
>
> What's cryptic about bash?
>

When you start doing serious scripting with bash it can become cryptic
but at the same time, it is also a powerful shell.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 1/20/2022 1:57 PM, Bill Gunshannon wrote:
> On 1/20/22 1:31 PM, Simon Clubley wrote:
>> It would be nice to have readability with the power however...
>
> shells are a lot more readable than PHP or PERL.

A lot of bad things has been said about Perl readability over the years,
but it is still used.

PHP has evolved a lot in the last decade. 7.x and 8.x (and Hack) are not
bad.

Arne

On 1/20/22 11:37 AM, Bill Gunshannon wrote:
> On 1/20/22 11:26 AM, Arne Vajhøj wrote:
>> On 1/20/2022 10:25 AM, Bill Gunshannon wrote:
>>> On 1/20/22 9:19 AM, Arne Vajhøj wrote:

>>>> but Perl
>>>> and Python are not *nix specific.
>>>
>>> Both were originally developed in the Unix environment.  Use in any
>>> other environment is an afterthought.
>>
>> They were developed on Unix but I don't think calling usage on
>> other platforms an afterthought is proper description.

In fact it's an offensive and ignorant description. It's more or less
like saying Fortran on VMS is an afterthought because it ran on
something else first.

>> When Larry Wall released the first public version of Perl the build
>> configuration included:
>>
>> <quote>
>> /* EUNICE:
>>   *    This symbol, if defined, indicates that the program is being
>> compiled
>>   *    under the EUNICE package under VMS.  The program will need to
>> handle
>>   *    things like files that don't go away the first time you unlink
>> them,
>>   *    due to version numbering.  It will also need to compensate for
>> lack
>>   *    of a respectable link() command.
>>   */
>> /* VMS:
>>   *    This symbol, if defined, indicates that the program is running
>> under
>>   *    VMS.  It is currently only set in conjunction with the EUNICE
>> symbol.
>>   */
>> </quote>
>>
>> so definitely Unix centric but VMS aware.
>
> EUNICE?  That's Unix running on top of VMS. :-)
> Can it be compiled and run if you set the VMS flag?

I've been involved with maintaining Perl on VMS for over twenty years
and it is certainly not an afterthought. The EUNICE support came and
went before my time and really has nothing to do with the current port,
which I believe originated in one of the early Perl 5 releases, maybe
about 1997 or so.

On 1/20/22 2:17 PM, Simon Clubley wrote:
> On 2022-01-20, Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 1/20/22 1:31 PM, Simon Clubley wrote:
>>> On 2022-01-19, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
>>>>
>>>> If the shell is that important for a platforms success or failure,
>>>> Linux whould have been dead by now. A more user-unfriendly interface
>>>> is hard do find.
>>>>
>>>
>>> What about JCL ? :-)
>>>
>>> Bash is cryptic, but it is also powerful.
>>
>> What's cryptic about bash?
>>
>
> When you start doing serious scripting with bash it can become cryptic
> but at the same time, it is also a powerful shell.
>

I say it again, What is cryptic about bash?
Show me one.

bill