Or you could have "native" bash ($SHELL) with WSL. But I assume not everyone is using it.

Cheers

Lars

Lars Liedtke
Software Entwickler

[Tel.] +49 721 98993-
[Fax] +49 721 98993-
[E-Mail] lal@solute.de<mailto:lal@solute.de>

solute GmbH
Zeppelinstraße 15
76185 Karlsruhe
Germany

[Logo Solute]

Marken der solute GmbH | brands of solute GmbH
[Marken]
[Advertising Partner]

Geschäftsführer | Managing Director: Dr. Thilo Gans, Bernd Vermaaten
Webseite | www.solute.de <http://www.solute.de/>
Sitz | Registered Office: Karlsruhe
Registergericht | Register Court: Amtsgericht Mannheim
Registernummer | Register No.: HRB 110579
USt-ID | VAT ID: DE234663798

Informationen zum Datenschutz | Information about privacy policy
https://www.solute.de/ger/datenschutz/grundsaetze-der-datenverarbeitung.php

Am 21.12.22 um 13:15 schrieb Albert-Jan Roskam:

On Dec 21, 2022 06:01, Chris Angelico <rosuav@gmail.com><mailto:rosuav@gmail.com> wrote:

On Wed, 21 Dec 2022 at 15:28, Jach Feng <jfong@ms4.hinet.net><mailto:jfong@ms4.hinet.net> wrote:
> That's what I am taking this path under Windows now, the ultimate
solution before Windows has shell similar to bash:-)

Technically, Windows DOES have a shell similar to bash. It's called
bash. :) The trouble is, most people use cmd.exe instead.

==== I use Git Bash quite a lot: https://gitforwindows.org/
Is that the one you're referring to?

Lars Liedtke <lal@solute.de> writes:
>Or you could have "native" bash ($SHELL) with WSL.

In this newsgroup, it would actually be obvious to use Python.
When commands are typed manually, this might be a bit verbose,
though. I mean

os.chdir( r'C:\EXAMPLE' )

versus

CD C:\EXAMPLE

. But whenever one feels like writing a "batch file" for cmd,
"Power Shell" or bash, one could consider to use Python instead.

Then, of course, there "cmd", ...

import os
import cmd

class PythonShell( cmd.Cmd ):

intro = 'Welcome to the Python shell. Type help or ? to list commands.\n'
prompt = '(Python) '
file = None

def do_cd( self, arg ):
'change directory: CD C:\EXAMPLE'
os.chdir( *parse( arg ))

def do_bye( self, arg ):
'Exit: BYE'
print( 'Thank you for using the Python Shell!' )
return True

def precmd(self, line):
line = line.lower()
return line

def parse( arg ):
return tuple( arg.split() )

print( __doc__ )
PythonShell().cmdloop()

On Thu, 22 Dec 2022 at 03:11, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>
> Lars Liedtke <lal@solute.de> writes:
> >Or you could have "native" bash ($SHELL) with WSL.
>
> In this newsgroup, it would actually be obvious to use Python.

Less obvious than you might think - partly because bash is just so
dang good that it's really really hard to outdo it :) Sure, bash has a
lot of weird and wonky edge cases, but it's an incredibly practical
shell to use.

> When commands are typed manually, this might be a bit verbose,
> though. I mean
>
> os.chdir( r'C:\EXAMPLE' )
>
> versus
>
> CD C:\EXAMPLE

Exactly. What's good for a programming language is often not good for a shell.

> class PythonShell( cmd.Cmd ):
>
> intro = 'Welcome to the Python shell. Type help or ? to list commands.\n'
> prompt = '(Python) '
> file = None
>
> def do_cd( self, arg ):
> 'change directory: CD C:\EXAMPLE'
> os.chdir( *parse( arg ))
>
> def do_bye( self, arg ):
> 'Exit: BYE'
> print( 'Thank you for using the Python Shell!' )
> return True

Sure, you can always create your own shell. But I think you'll find
that, as you start expanding on this, you'll end up leaning more
towards "implementing bash-like and/or cmd-like semantics in Python"
rather than "creating a Python shell". Shells, in general, try to
execute programs as easily and conveniently as possible. Programming
languages try to stay inside themselves and do things, with subprocess
spawning being a much less important task.

Fun challenge: see how much you can do in bash without ever forking to
another program. And by "fun", I mean extremely difficult, and by
"challenge" I really mean "something you might have to do when your
system is utterly hosed and all you have available is one root shell".

It's amazing how far you can go when your hard drive has crashed and
you desperately need to get one crucial login key that you thought you
had saved elsewhere but hadn't.

ChrisA

On 12/21/22 11:22, Chris Angelico wrote:
> On Thu, 22 Dec 2022 at 03:11, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>>
>> Lars Liedtke <lal@solute.de> writes:
>>> Or you could have "native" bash ($SHELL) with WSL.
>>
>> In this newsgroup, it would actually be obvious to use Python.
>
> Less obvious than you might think - partly because bash is just so
> dang good that it's really really hard to outdo it :) Sure, bash has a
> lot of weird and wonky edge cases, but it's an incredibly practical
> shell to use.
>
When you make a statement like that, Chris, you should also note that
every single one of those "wonky edge cases" is documented down to the
last dotted i. Bash's docs will kill a good sized pulp tree, needing
around a ream of paper to print on a duplex printer. I know, I did it
around a decade ago. If you like to write scripts, having a dead tree
copy of the docs at your elbow in incredibly useful. That huge man page
does not cover it like the printed docs do.

>> When commands are typed manually, this might be a bit verbose,
>> though. I mean
>>
>> os.chdir( r'C:\EXAMPLE' )
>>
>> versus
>>
>> CD C:\EXAMPLE
>
> Exactly. What's good for a programming language is often not good for a shell.
>
>> class PythonShell( cmd.Cmd ):
>>
>> intro = 'Welcome to the Python shell. Type help or ? to list commands.\n'
>> prompt = '(Python) '
>> file = None
>>
>> def do_cd( self, arg ):
>> 'change directory: CD C:\EXAMPLE'
>> os.chdir( *parse( arg ))
>>
>> def do_bye( self, arg ):
>> 'Exit: BYE'
>> print( 'Thank you for using the Python Shell!' )
>> return True
>
> Sure, you can always create your own shell. But I think you'll find
> that, as you start expanding on this, you'll end up leaning more
> towards "implementing bash-like and/or cmd-like semantics in Python"
> rather than "creating a Python shell". Shells, in general, try to
> execute programs as easily and conveniently as possible. Programming
> languages try to stay inside themselves and do things, with subprocess
> spawning being a much less important task.
>
> Fun challenge: see how much you can do in bash without ever forking to
> another program. And by "fun", I mean extremely difficult, and by
> "challenge" I really mean "something you might have to do when your
> system is utterly hosed and all you have available is one root shell".
>
> It's amazing how far you can go when your hard drive has crashed and
> you desperately need to get one crucial login key that you thought you
> had saved elsewhere but hadn't.
>
> ChrisA

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>

On Thu, 22 Dec 2022 at 03:58, gene heskett <gheskett@shentel.net> wrote:
>
> On 12/21/22 11:22, Chris Angelico wrote:
> > On Thu, 22 Dec 2022 at 03:11, Stefan Ram <ram@zedat.fu-berlin.de> wrote:
> >>
> >> Lars Liedtke <lal@solute.de> writes:
> >>> Or you could have "native" bash ($SHELL) with WSL.
> >>
> >> In this newsgroup, it would actually be obvious to use Python.
> >
> > Less obvious than you might think - partly because bash is just so
> > dang good that it's really really hard to outdo it :) Sure, bash has a
> > lot of weird and wonky edge cases, but it's an incredibly practical
> > shell to use.
> >
> When you make a statement like that, Chris, you should also note that
> every single one of those "wonky edge cases" is documented down to the
> last dotted i. Bash's docs will kill a good sized pulp tree, needing
> around a ream of paper to print on a duplex printer. I know, I did it
> around a decade ago. If you like to write scripts, having a dead tree
> copy of the docs at your elbow in incredibly useful. That huge man page
> does not cover it like the printed docs do.
>

Oh yes, absolutely true. Its wonkiness is dependable and consistent;
but it is definitely quirky (look at all the different ways to embed
arguments into things, and the ways that $*, $@, "$*, and "$@" behave
when put into variables). Not usually a problem, but it does sometimes
leave you thinking "wow, wouldn't it be easier to just use something
like Python?". And in the complicated cases, yeah, it can be. But in
the simple cases? Bash rocks.

ChrisA

On 21 Dec 2022 13:39:14 GMT, ram@zedat.fu-berlin.de (Stefan Ram) declaimed
the following:

>Lars Liedtke <lal@solute.de> writes:
>>Or you could have "native" bash ($SHELL) with WSL.
>
> In this newsgroup, it would actually be obvious to use Python.
> When commands are typed manually, this might be a bit verbose,
> though. I mean
>
>os.chdir( r'C:\EXAMPLE' )

os.chdir("C:/Example")

is perfectly valid in the Windows API. It is only the command line
processor that requires \ to differentiate from command options.

If that is still too much to enter, I'd recommend one look at REXX...
Any statement that is not parsable as a REXX command is normally sent to
the shell (unless one has specified a different command processor), so...

"CD C:\Example"

(with the quotes) is sufficient. (Hmm I may have to check that -- it may
only CD for the one command, then revert to parent directory)

--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

gene heskett <gheskett@shentel.net> writes:
>When you make a statement like that, Chris, you should also note that
>every single one of those "wonky edge cases" is documented down to the
>last dotted i.

The Windows' cmd is wonky too, but not well documented.
For one example: The circumflex "^" can continue a command line.
But when one wants to use a literal circumflex "^" in a cmd
file or in a file name, it has to be escaped in ways that
seem to be quite irregular. This has been documented by
amateurs, but not by Microsoft AFAIK. (Search for "Note that
the phases described below are only a model of how the batch
parser works.".)

Here's a Windows cmd command file I wrote:

ffmpeg -i "source^^.mp4" ^
"target^^^^.mkv"

. The actual source and target file names are supposed to be
"source^^.mp4" and "target^^.mkv", but in the line continuation,
the "^" has to be escaped, while in the first line it has not!

(Ffmpeg is another piece of software with quite complex options.)

The following Windows cmd file creates three files "aa.txt",
"a^a.txt" and "a^^a.txt" with a delay of one minute between
each creation. Then it loops through the directory and prints
some stats about the files. All the fuss with the "SET" command
is only necessary to correctly iterate through files in a
directory in the presence of the possibility that file names
may contain the circumflex "^"! (Warning: The script will
overwrite some files in the directory it is executed in as
indicated by the use of ">" below". The file has been edited
in the newsreader before posting it and was not tested again
after that editing took place.)

echo 11111>aa.txt
timeout 62
echo 222222>a^^a.txt
timeout 62
echo 3333333>a^^^^a.txt

dir *.txt

setlocal enabledelayedexpansion
for /f %%i in ('dir /b *.txt') do (
SET "a=%%i"
SET "b=!a:^=^^!"
call :sub !b!
) goto :eof

:sub
SET "A=%1"
SET "B=%1"
SET "a=%a:^=^^%"
call :suba %A%, %B%
goto :eof

:suba
echo.&echo.
echo The file %1 was created on %~t2 and contains %~z2 bytes.
echo Contents:
type %1
goto :eof

And this script only handles the special character "^".
There may be other characters that also require special
handling. (I wrote the above script after someone asked
in another Newsgroup how to do this.)

Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
> If that is still too much to enter, I'd recommend one look at REXX...
>Any statement that is not parsable as a REXX command is normally sent to
>the shell (unless one has specified a different command processor), so...

I still have vague but fond memories of embedding something
into my texts in the Amiga Cygnus-Ed editor which then would
serve as Cygnus-Ed "macros" activated via hotkeys. I believe
these snippets were written by me in AREXX (REXX for the Amiga,
1987 by William S. Hawes). I forgot all details, though.

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>echo 11111>aa.txt
>timeout 62
>echo 222222>a^^a.txt
>timeout 62
>echo 3333333>a^^^^a.txt
>
>dir *.txt
>
>setlocal enabledelayedexpansion
>for /f %%i in ('dir /b *.txt') do (
>SET "a=%%i"
>SET "b=!a:^=^^!"
>call :sub !b!
>)
>goto :eof
>
>:sub
>SET "A=%1"
>SET "B=%1"
>SET "a=%a:^=^^%"
>call :suba %A%, %B%
>goto :eof
>
>:suba
>echo.&echo.
>echo The file %1 was created on %~t2 and contains %~z2 bytes.
>echo Contents:
>type %1
>goto :eof

A similar Python script might be longer, but it deals with
getting the job done and not with fighting irregularities.
(Warning: This script may create/overwrite/delete files!)

import datetime
import pathlib
import time

for content, name in\
( ( '11111', 'aa.txt' ),( '222222', 'a^a.txt' ), ( '3333333', 'a^^a' )):
with open( name, "w" ) as stream:
print( content, file=stream )
time.sleep( 62 )

for file in pathlib.Path.cwd().glob( '*.txt' ):
print( 'The file '+ str( file )+' was created on '+
str( datetime.datetime.fromtimestamp( file.stat().st_ctime ))+
' and contains '+ str( file.stat().st_size )+' Bytes. ' )
print( 'Contents:' )
with open( file, 'r' )as stream: print( stream.read() )

On 21 Dec 2022 17:49:35 GMT, ram@zedat.fu-berlin.de (Stefan Ram) declaimed
the following:

>Dennis Lee Bieber <wlfraed@ix.netcom.com> writes:
>> If that is still too much to enter, I'd recommend one look at REXX...
>>Any statement that is not parsable as a REXX command is normally sent to
>>the shell (unless one has specified a different command processor), so...
>
> I still have vague but fond memories of embedding something
> into my texts in the Amiga Cygnus-Ed editor which then would
> serve as Cygnus-Ed "macros" activated via hotkeys. I believe
> these snippets were written by me in AREXX (REXX for the Amiga,
> 1987 by William S. Hawes). I forgot all details, though.
>
Probably -- AREXX was the most capable version of REXX I've encountered
(Regina REXX and ooREXX seem to be limited in the command processors it
understands -- basically the equivalent of direct execution ["exec"? style]
or with a shell). It allowed /any/ application that opened an AREXX port to
be command processor. Even the basic text editor could be controlled via
AREXX. Heck, one could even write AREXX scripts that could open ports and
become command processors for other scripts.

--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/