[QUESTION] Scripts

[Copy-link]

Could you clarify what you mean here? https://github.com/wez/wzsh#non-goals

Batch is a horrible, horrible scripting language, and while PowerShell is much better in that regard, its backwards/forwards compatibility is wretched. And while WSL provides an easy way to utilize bash scripts for personal use, usually when I make a script it's for people who aren't so tech-savvy - which means WSL is typically out of the question. But, distributing a single binary inside of a zip file with a script, that's very doable.

Will some form of shell script through wzsh be possible?

[wez]

Yeah, expanding on that point:

• Many shells end up wanting to replace /bin/sh, and this means growing stricter posix compatibility in order for scripts to have the semantics that the author intended. That's a non-goal for wzsh because strict 100% posix compatibility is at odds with Windows platform support in a number of areas that impact how the core of the shell functions.
• The language in most (all?) shells can be read from a file and not just typed in interactively, and this leads to folks using it to script the shell. That's OK, but has some conflicting requirements: a good interactive shell makes it convenient for a user to write ad-hoc snippets with minimal fuss, which is also fine for trivially sized scripts, but when the script gets larger (my subjective and experience driven threshold is ~200 lines), shell scripts rapidly become unmaintainable because the overhead of handling errors and various other situations is higher and the scripts become much harder to reason about and become a source of bugs.

With the above in mind: yes, the language and syntax that you use in wzsh will also be readable from a file and look very much like bourne shell style syntax (in fact, starting in 437d3f53d37297bb652078cc6a96f27b8235f0c9 your ~/.config/wzsh/startup.wzsh is sourced to load aliases), but may be semi-intentionally missing some features that make it great for scripting. I'm not saying I'll refuse to fill in some gaps, just that each of those will be considered with the above in mind.

Not 100% related to your question, but another thing to consider is that the unix philosophy is to push a lot of the heavy lifting out of the shell and into utilities such as grep, sed and so on that perform text extraction and manipulation. Some of these I'll build into wzsh as in-process builtins, but I don't think it is feasible to embed them all here, so there will probably be some gaps in those utilities when it comes to scripting!

[Copy-link]

Some of these I'll build into wzsh as in-process builtins, but I don't think it is feasible to embed them all here, so there will probably be some gaps in those utilities when it comes to scripting!

Honestly, the syntax is what matters most to me, ESPECIALLY the command substitution. In batch, the only way to assign the output of a command to a variable is a for /f loop - this alone drives me crazy.

For the utilities, I could use something like busybox64.exe, which has a lot of utilities bundled into it, so I'd just be distributing wzsh.exe, busybox64.exe, and a script. I do hope wzsh will have it's own built-in version of cat though, I haven't really seen it ported to Windows and I suspect an incompatibility with conhost is probably why.

Ideally, I'm hoping I can make a 'hybrid' command script that starts with the terminal and launches into wzsh, similar to the scripts in this thread. Since a shebang isn't going to be necessary I think, I'll be able to accomplish that like this:

echo >/dev/null # >NUL & @echo off & goto:Batch

# Area for WZSH syntax script #

exit 0

:Batch
:: whatever batch commands need to run first for whatever reason
echo|set /p="butts"&echo/

:: then launching the wzsh script section up proper:

or

echo >/dev/null # >NUL & @start /b wzsh.exe --script "%~s0" %*

[wez]

I pushed a couple of quick commits that make it easier to play with the state of scripting as it exists today. It is still pretty early and rough feeling right now!

re: busybox, you could put something like this into your startup.wzsh to bootstrap things as they stand today; this defines ls and grep functions that run busybox and pass through all arguments; we don't have alias because posix requires that aliases be expanded by the tokenizer machinery and that is insane.

which -q busybox64.exe && ls() { busybox64 ls $* }
which -q busybox64.exe && grep() { busybox64 grep $* }

(Ideally you'd just use a simple if conditional to check for busybox just once but I haven't put if in the parser yet!)

[wez]

For the sake of making it easier to see without requiring you to build it, those commits allow this:

$ wzsh -h
wzsh 0.1.0
Wez Furlong
Wez's Shell
http://github.com/wez/wzsh

USAGE:
    wzsh [FLAGS] [file]

FLAGS:
    -h, --help          Prints help information
        --no-startup    Skip loading startup.wzsh
    -V, --version       Prints version information

ARGS:
    <file>    Instead of starting the interactive REPL, load script from file and execute it

echo ls | wzsh
<runs ls>

wzsh filename.wzsh
<runs filename.wzsh>

wzsh < filename.wzsh
<runs filename.wzsh>

[Copy-link]

Oh, nice! That'll be really useful.

Regarding aliases, I've honestly never found them very useful even in Linux, they're so unreliable, I always go back to using symbolic links. In Windows, however, symbolic links can often lead binaries to not be able to find their dependencies.

The reason for this tangent being, and this is wildly off-topic, but I suspect you would find 'shims' very useful for your Windows environment. They're not widely used yet, mainly just Chocolatey and Scoop, but I came across an Unlicense implementation of them recently that might be useful to you in some capacity: https://github.com/71/scoop-better-shimexe (Don't let the name fool you, this works by itself, Scoop isn't required.)

Basically shim.exe is just a wrapper, you rename it to whatever binary it's going to be redirecting to, and then you have a .shim file of the same name. So say you wanted to make a shim of ripgrep and have it apply the 'ignore case' argument automatically:

copy shim.exe rg.exe
echo+path = C:\file path\to\rg.exe>rg.shim & echo+args = -i>>rg.shim

Just make sure the .shim files ends in a linebreak, for some reason that messes up this particular implementation, other than that, it's the best shim implementation I've seen.

[Copy-link]

Also, something that functions like cmd /k or powershell -NoExit would be good for the times you want wzsh to stay open after execution.

[wez]

BTW, I hooked up very basic windows builds; the artifacts are captured in the github actions UI which you can get into by clicking here: https://github.com/wez/wzsh/actions

From there you can select a build and then download the binary:

I'll refine this a bit later, but this should be sufficient to easily play with the latest build, which has some basic scripting support now; see the top level readme for a checklist of the current status.