Support custom shells

[Taitava]

I thought I had already created a discussion for this, but didn't find one. But anyway here it is now.

0.7.0 will add an ability to choose a shell that will be used for executing shell commands. But the shell choice is limited to the following options:

Windows:

• CMD
• PowerShell 5
• PowerShell Core

Linux & Mac:

• Bash
• Dash
• Zsh

If a user happens to have some other shell than one of those defined in their operating systems's user preferences, SC 0.7.0 will not allow executing commands on that shell, because it does not know, what kind of special character escaping method it should use.

I want to allow users to add their own shells in the main settings view. When they define a new shell, they need to select, will it use the same escaping that Bash etc. uses (\ escape character), or PowerShell escaping (` escape character). After defining a new shell, it can be selected as a default shell for all commands, or as for specific commands.

Edit 2022-07-21: Added the following:

Properties that custom shells should define

• Unique identifier (more on that below).
• Shell executable path
• Escaping: Bash style, PowerShell style, or No escaping (not recommended). Later: consider is it possible to allow users to define custom escaping mechanisms - but that's not a discussion for this particular topic, it could have a new discussion.
  Added 2022-11-14:
• Directory separator. Used by all variables that return any file/folder paths. Options:
  • /
  • \
  • Or: The one used by the current operating system (selected by default).
• A mechanism for converting a path into a format understood by the particular shell. E.g. if {{file_path}} would normally return C:\MyVault\MyNote.md, and if using Windows Subsystem for Linux (WSL), then the Windows path format will not work, and it needs to be converted to a path suitable for WSL: /mnt/c/MyVault/MyNote.md. Consider should this be a JavaScript snippet, or would regex be enough?
• Path separator. On Windows it's ;, on Linux and macOS it's :. Used when augmenting $PATH environment variable. There might be other use-cases as well, whenever multiple paths must be listed in a single string. (Added 2022-12-05).

[Taitava]

Exportability of shell commands using a custom shell

Custom shells need to be exportable (see #151) so that exported shell commands can use them. This means that custom shells need to have their identifiers based on the shell executable's name, so that if two users define e.g. MINGW as a custom shell, they should have the same identifier in their configurations. This allows them to share MINGW shell commands between each other without the need to have duplicate configurations for MINGW with two different identifiers.

For built-in shell definitions, a shell identifier is currently determined from the shell executable's path: Remove the directory from the path, and use the file name as the shell's identifier. E.g. path /bin/bash -> use bash as the identifier.

Allow exceptionally changing the identifier

If a user wants to use e.g. two different installations of MINGW, they should be able to define two MINGW shells. In this case, the shell definitions should have different identifiers. When creating a new shell definition, show a warning to the users saying that The same (or similar) shell is already defined, but you can create another, if you want. If the user proceeds, replace the shell file name identifier with a random identifier, e.g. MINGW would be replaced with something like fdkjerjh43. Don't use sequential numbering like MINGW2, because the number could be mixed up with a software version number, and also there's no benefit in keeping the shell file name in the identifier if the identifier contains a sequential number.

[TheRealGramdalf]

Just thought I'd add my two cents

I'm in the process of setting up a vault set up for a specific task (writing), and I'm adding all sorts of buttons and whatnot. Since I want it to be cross platform, I decided to use shell (in this case ash) scripts that can be run with busybox, which is available on linux/macOS as well as windows (through frippery.org).

I was just curious what your thoughts were on integrating busybox into SC natively rather than using my somewhat hacky solution (a folder which gets added to PATH that contains the busybox binary plus symlinks for the different commands). It should be relatively easy to do, I'm just curious as to whether that's a direction you want your project to go. If so, then I'd wait for that to be added, otherwise I'll continue with my current setup.

I hope that made any semblance of sense, if not just ask for (Specific!) clarification.

Frippery busybox: https://frippery.org/busybox/index.html
Linux/MacOS busybox: https://www.busybox.net/about.html

Edit: Some things I should have clarified

symlinks are to call busybox directly without specifying /path/to/busybox grep, rather running /path/to/grep where grep is a symlink to busybox.

My idea for implementation would be this:

• Add the binaries for busybox to SC
• Enable the option to create a command, and under the environments tab, have a busybox option
• the user can then enter a path (relative to the vault) to an ash/sh script that busybox will execute
• Add some way to pass variables to the script, such as using -{{var}} args and a corresponding bit in the script, or somehow enabling the use of {{var}} directly in the script
• In this way, you can unlock the true potential of SC by adding official support for scripts that will work cross platform. This way, users could share scripts (maybe in a repo somewhere?), so that each person doesn't have to build their commands from scratch, as well as so many more possibilities
• In my case, I would use it to create a set of scripts to be used in conjunction with the buttons plugin to make a 'template' vault which people can use, complete with a set of functions (such as something I currently have which takes a todo file, parses it for completed tasks, and sorts them into completed/incomplete respectively). But like I said- there is infinite customizability simply by including busybox. It would also help in making each vault more independent- people can have scripts that will run regardless of device, giving a level of faux containerization.

But I digress.

[Taitava]

Hi! 🙂 Thank you for your suggestions! 😎

Since I want it to be cross platform, I decided to use shell (in this case ash) scripts that can be run with busybox, which is available on linux/macOS as well as windows (through frippery.org).

Being able to use the same scripting language across different platforms is a very good idea. I'm not familiar with Busybox, but that could receive support via custom shells in the future.

I was just curious what your thoughts were on integrating busybox into SC natively rather than using my somewhat hacky solution (a folder which gets added to PATH that contains the busybox binary plus symlinks for the different commands). It should be relatively easy to do, I'm just curious as to whether that's a direction you want your project to go. If so, then I'd wait for that to be added, otherwise I'll continue with my current setup.

First of all, I have to admit that expanding the support of different shells will take a lot of time, and so I'd suggest that you continue with your current setup for now. I don't recommend waiting for this development.

That being said, supporting more shells is an important missing piece for this plugin. I just want to plan it out carefully.

Also, I could better clarify what shells would be considered custom, and what would be core shells supported natively by this plugin:

• Core shells are shells that can be found on a great amount of operating systems used by the Obsidian community. This plugin's documentation and release testing should aim for a good level of support for each core shell. So, only shells that would be popular among the userbase, should be included as core shells.
• Custom shells would be shells that are not installed by default on any operating system that is popular among the userbase of Obsidian. I'd consider Busybox being one.

• Add the binaries for busybox to SC

Do you mean that SC could download and install the Busybox binaries automatically for the user? I'm sorry, but I don't see that feasible. I think that if a user wants to use a shell that is not yet installed on their machine, they should do the downloading and installation manually. I don't see that the benefit of an automatic installation would be large enough to outweight the effort to develop such a feature.

• Enable the option to create a command, and under the environments tab, have a busybox option

When custom shells will be supported, yes this could be done.

• the user can then enter a path (relative to the vault) to an ash/sh script that busybox will execute

Would it be the same as currently you can write the script path to the shell command field?

• Add some way to pass variables to the script, such as using -{{var}} args and a corresponding bit in the script, or somehow enabling the use of {{var}} directly in the script

Values from {{variables}} can be passed to scripts as arguments using the following guides:

• Documentation: https://publish.obsidian.md/shellcommands/Variables/Variables+-+general+principles#Passing+variable+values+into+external+script+files
• A discussion: variable won't work when using script.sh file #200 (comment)

Or did you mean something else?

• In this way, you can unlock the true potential of SC by adding official support for scripts that will work cross platform. This way, users could share scripts (maybe in a repo somewhere?), so that each person doesn't have to build their commands from scratch, as well as so many more possibilities

Yes, there will probably be a GitHub repository where users could share their shell commands, once importing / exporting shell commands gets implemented in the far future.

As for the crossplatform support, your idea of a single shell that could be used on all platforms, is really good! I was previously thinking about using e.g. Bash on all the three supported OSes: Linux, macOS, and Windows with the support of WSL (Window Subsystem for Linux). The problem with any Bourne family shells is that even if the actual shell stays the same, a lot of the commands differ between Linux and macOS.

[TheRealGramdalf]

Let me start with what busybox is.

(Taken from the website)

BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc. The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts. BusyBox provides a fairly complete environment for any small or embedded system.

It contains a ton of different tools, 402 at the time of writing. Almost all you could want for scripting- grep, sed, awk, cat, wget, and a whole lot more (I added a list with all the different tools below).
The beauty of busybox is that it is POSIX compliant (afaik), as it contains both sh and ash shells. It is a single, tiny binary (1.1mb!), which would make it perfect for SC- I would consider it an 'embedded device' of sorts, if you get my meaning.
The other great thing is that it is a static binary that remains consistent between OSes. With the possible exception of windows (as the frippery build may be slightly different), everything should remain functionally the same, no matter what distro you use. Vanilla busybox is compatible with linux/macos, and the frippery build (around 600kb) is compatible with windows.

In this way you could bundle it with SC (cause it's tiny!), and then you have something consistent between all three OSes.

As far as escaping characters (which I think is the most problematic thing for development), you should be able to use existing bash escaping- or even just sh/ash, I'm sure one exists out there. True, it's not as common as bash/dash/zsh, but it's still used in some places, mainly embedded devices (think router software- cisco uses busybox for some of their APs)

I think a key step would be to add busybox as a core shell. While you could use WSL, busybox is much more versatile, easier on the end user, and in general just simpler. You don't have to deal with shared files in WSL (which I'm told is somewhat janky), it just works out of the box.

as for difficulty of installing busybox for the user, it's dead simple- just include the single file. The way you use busybox is similar to how shells work. You call the binary (busybox), and then have your next arg as the command, such as busybox grep. Busybox will then call the grep program internally. Alternatively, you can use symlinks. If you make a link to the busybox binary (ln -s /path/to/busybox /path/to/grep, if you call the symlink, busybox will automatically call grep (rather than having to add busybox at the beginning). Think of each symlink as pointing to a specific program within the single binary.

Would it be the same as currently you can write the script path to the shell command field?
Yes

Values from {{variables}} can be passed to scripts as arguments using the following guides:
Exactly what I was looking for, thanks!

The problem with any Bourne family shells is that even if the actual shell stays the same, a lot of the commands differ between Linux and macOS.
This is probably redundant at this point, but just to be super clear: the reason there are those different quirks is that each system has slightly different implementations. MacOS uses something other than gnu coreutils to provide your basic programs (grep, awk, etc.), so it differs from linux. Busybox bundles those all into the binary, so it stays the same regardless of the system, since it is standalone.

A couple of thoughts regarding the technical side of things:
You would probably need to have all the binaries bundled in with SC, so that if a user uses the vault on multiple devices, the busybox binary is available for that device. You would need to add some extra logic based on platform- most of it should already be in place (as you have support for differing between linux/macos/windows), but you would need a tiny bit of extra logic based on the cpu architecture of the system. There are different builds for each architecture (32 bit, 64 bit, arm, x86, etc), so you would probably need to include all of them in SC and just call whichever one pertains to the current system (I'm not sure if obsidian will tell you what cpu arch the computer uses, but I'm fairly certain it won't be super hard).

As promised, here is a list of the different commands busybox can use:

'['              factor           link            popmaildir     tac
'[['             fakeidentd       linux32         poweroff       tail
 acpid           fallocate        linux64         powertop       tar
 addgroup        false            linuxrc         printenv       taskset
 adduser         fatattr          ln              printf         tc
 adjtimex        fbset            loadfont        ps             tcpsvd
 ar              fbsplash         loadkmap        pscan          tee
 arch            fdflush          logger          pstree         telnet
 arp             fdformat         login           pwd            telnetd
 arping          fdisk            logname         pwdx           test
 ascii           fgconsole        losetup         raidautorun    tftp
 ash             fgrep            lpd             rdate          tftpd
 awk             find             lpq             rdev           time
 base32          findfs           lpr             readlink       timeout
 base64          flashcp          ls              readprofile    top
 basename        flash_eraseall   lsattr          realpath       touch
 bc              flash_lock       lsmod           reboot         tr
 blkdiscard      flash_unlock     lsof            reformime      traceroute
 blkid           flock            lspci           renice         traceroute6
 blockdev        fold             lsscsi          reset          true
 bootchartd      free             lsusb           resize         truncate
 brctl           freeramdisk      lzcat           resume         ts
 bunzip2         fsck             lzma            rev            tty
 busybox         fsck.minix       lzop            rm             ttysize
 bzcat           fsfreeze         lzopcat         rmdir          tunctl
 bzip2           fstrim           makedevs        rmmod          tune2fs
 cal             fsync            makemime        route          ubiattach
 cat             ftpd             man             rpm            ubidetach
 chat            ftpget           md5sum          rpm2cpio       ubimkvol
 chattr          ftpput           mdev            rtcwake        ubirename
 chgrp           fuser            mesg            runlevel       ubirmvol
 chmod           getopt           microcom        runsv          ubirsvol
 chown           getty            mim             runsvdir       ubiupdatevol
 chpasswd        grep             mkdir           rx             udhcpc
 chpst           groups           mkdosfs         script         udhcpc6
 chroot          gunzip           mke2fs          scriptreplay   udhcpd
 chrt            gzip             mkfifo          sed            udpsvd
 chvt            halt             mkfs.ext2       sendmail       uevent
 cksum           hd               mkfs.minix      seq            umount
 clear           hdparm           mkfs.reiser     setarch        uname
 cmp             head             mkfs.vfat       setconsole     uncompress
 comm            hexdump          mknod           setfattr       unexpand
 conspy          hexedit          mkpasswd        setfont        uniq
 cp              hostid           mkswap          setkeycodes    unix2dos
 cpio            hostname         mktemp          setlogcons     unlink
 crc32           httpd            modinfo         setpriv        unlzma
 crond           hush             modprobe        setserial      unlzop
 crontab         hwclock          more            setsid         unshare
 cryptpw         i2cdump          mount           setuidgid      unxz
 cttyhack        i2cget           mountpoint      sh             unzip
 cut             i2cset           mpstat          sha1sum        uptime
 date            i2ctransfer      mt              sha256sum      users
 dc              id               mv              sha3sum        usleep
 dd              ifconfig         nameif          sha512sum      uudecode
 deallocvt       ifenslave        nc              showkey        uuencode
 delgroup        ifplugd          netstat         shred          vconfig
 deluser         inetd            nice            shuf           vi
 depmod          init             nl              slattach       vlock
 devmem          inotifyd         nmeter          sleep          volname
 df              insmod           nohup           smemcap        w
 dhcprelay       install          nologin         softlimit      wall
 diff            ionice           nproc           sort           watch
 dirname         iostat           nsenter         split          watchdog
 dmesg           ip               nslookup        ssl_client     wc
 dnsd            ipaddr           ntpd            stat           wget
 dnsdomainname   ipcalc           nuke            strings        which
 dos2unix        ipcrm            od              stty           who
 dpkg            ipcs             openvt          su             whoami
 du              iplink           partprobe       sulogin        whois
 dumpkmap        ipneigh          passwd          sum            xargs
 dumpleases      iproute          paste           sv             xxd
 echo            iprule           patch           svc            xz
 ed              iptunnel         pgrep           svlogd         xzcat
 egrep           kbd_mode         pidof           svok           yes
 eject           kill             ping            swapoff        zcat
 env             killall          ping6           swapon         zcip
 envdir          killall5         pipe_progress   switch_root
 envuidgid       klogd            pivot_root      sync
 expand          last             pkill           sysctl
 expr            less             pmap            syslogd

linux-bin.zip

I'll also include a .zip file with the busybox binary and all the symlinks ready to go so you can try it out for yourself. It's for linux x86, let me know if you need it for a different arch.

[TheRealGramdalf]

I can't resist, I'm just always amazed at how small people can make computers. Like this is a fully functional shell with over 400 programs, all in under 2mb! Crazy.

[TheRealGramdalf]

I'll continue working on my current setup. I'll send you a link so you can see how it works once I have it mostly functional, so you can use that as a model for implementing it in SC if you like. It will be via github, so you can download the vault and see everything that's going on :)

[Taitava]

Let me start with what busybox is.

Thank you for your introduction on BusyBox! 🙂

In this way you could bundle it with SC (cause it's tiny!), and then you have something consistent between all three OSes.

Yea, the benefits are clear for a shell that works consistently on all the three supported operating systems. I'm willing to consider supporting it. But I will not budle the binary with SC. I'll come to that later.

As far as escaping characters (which I think is the most problematic thing for development), you should be able to use existing bash escaping- or even just sh/ash, I'm sure one exists out there.

Yes, escaping characters in variable values should be easy to do - assuming ash will not have any surprising differences when compare to bash. I'm not expecting too much trouble for escaping.

I think a key step would be to add busybox as a core shell. While you could use WSL, busybox is much more versatile, easier on the end user, and in general just simpler. You don't have to deal with shared files in WSL (which I'm told is somewhat janky), it just works out of the box.

Yes, WSL is a bit complex.

as for difficulty of installing busybox for the user, it's dead simple- just include the single file.

There's a few reasons why I will not include the binary permanently to this plugin:

1. I don't see most users using BusyBox. The first step should be to allow users to optionally install it. If it gains popularity among the users of SC, then the download/installation process can be improved to make it easier.
2. AFAIK, Obsidian does not support including any attachment files in plugins' release files. Only the following three files are supported (correct me if I'm wrong):
   • main.js - the plugin's source code.
   • styles.css - layout.
   • manifest.json - meta information about the plugin.
     Some plugins circumvent this limitation by downloading files (after asking a permission from user). This could be a considerable option here, but it requires quite much work and would be for a later step. It would be needed to make sure that we know a permanent download URL that probably does not change, and would need to design a BusyBox version update process, too. I.e. provide users a way to check for new BusyBox version, and if one is available, an option for upgrading. All this semi automatic downloading/installing is something that is a bit off from the central point of just developing support for BusyBox.
3. Even if a binary could be included among the plugin's files, it would be a bit outdated version in practise. When a new version of BusyBox is released, it could take a great amount of time for me to update it in this plugin. Users would have to either update it manually (= replace the binary that came with the plugin) or wait until it's updated in this plugin.
4. I can't include statically stuff that I cannot monitor for safety - even if the source code is available, as I don't have the resources for reading it thrught and understanding it. But if a user is offered an option to download it (or not download it), then there's no issue.

So the first step would be to provide users with clear instructions on where they can find the latest version of BusyBox (for their OS) and how they can install it on their machine and set it up on the SC plugin. A one page documentation should cover it all from start to finish.

• Later, when exporting/importing settings is implemented, the documentation page could provide a copy-paste definition for a custom shell that constain all the configuration details needed by the plugin.
• And perhaps at some point implement the automatic download, but this is still uncertain.

The way you use busybox is similar to how shells work. You call the binary (busybox), and then have your next arg as the command, such as busybox grep. Busybox will then call the grep program internally.

Yea. Node.js has a solid way for calling different shells. I just need to tell Node.js's child_process a path to a shell, and then I can just pass the command that the shell should execute. I don't need to combine the shell path and the command together myself. So, implementing BusyBox support should be quite trivial at least from this angle.

Values from {{variables}} can be passed to scripts as arguments using the following guides:

Exactly what I was looking for, thanks!

You're welcome! 🙂

The problem with any Bourne family shells is that even if the actual shell stays the same, a lot of the commands differ between Linux and macOS.

This is probably redundant at this point, but just to be super clear: the reason there are those different quirks is that each system has slightly different implementations. MacOS uses something other than gnu coreutils to provide your basic programs (grep, awk, etc.), so it differs from linux. Busybox bundles those all into the binary, so it stays the same regardless of the system, since it is standalone.

Yea, BusyBox would solve this nicely. 👍

A couple of thoughts regarding the technical side of things: You would probably need to have all the binaries bundled in with SC, so that if a user uses the vault on multiple devices, the busybox binary is available for that device. You would need to add some extra logic based on platform- most of it should already be in place (as you have support for differing between linux/macos/windows), but you would need a tiny bit of extra logic based on the cpu architecture of the system. There are different builds for each architecture (32 bit, 64 bit, arm, x86, etc), so you would probably need to include all of them in SC and just call whichever one pertains to the current system (I'm not sure if obsidian will tell you what cpu arch the computer uses, but I'm fairly certain it won't be super hard).

Good point. And actually one reason more for not including the binaries statically. There would be multiple BusyBox binaries to keep up-to-date, and each user would have multiple binaries of which they would only use one on their particular device (or none, if they will not use BusyBox at all).

Thank you for the CPU architecture point! 🙂 It's something that needs to be taken into account if creating a (semi) automatic download process for BusyBox. The plugin should download the correct binary for the user. Or, if the plugin would provide a download link for the user, the link could include the correct binary architecture. I, too, do not know if the Node.js or Electron libraries (that Obsidan uses) provide information about CPU architecture.

To sum it up

• I think we will have nice support for BusyBox, even if the installation part will differ from what you have suggested.
• The setting up part can be improved later, the first focus should be on the center point of just supporting the shell. After all, it's about experimenting and changing things if they don't seem to work well enough.
• If the BusyBox support will turn out to work well after implementation, the idea of using BusyBox should be spread among the community . Personally, I'm not good at this kind of influencing. I guess BusyBox users should just be active on posting example commands for it. But that's not today's thing. 🙂

I'll continue answering you

• I'll check the zip you provided.
• I'll answer your other comments in this discussion after checking the zip.

[Taitava]

I've started developing custom shells

The progress can be followed in issue #297, but I'll probably add some summary updates on this discussion, too.

I'm aiming this to be released in 0.19.0, so not the next 0.18.0 release, but after that.

[Taitava]

Difficulties with WSL and MinGW-w64

I'll write just a small update. The basic UI and settings structure is now in place as well as some class structure changes, althought some changes to the settings are still needed. But at least the structure now allows me to do some trials.

Node.js's child_process uses -c switch to pass commands to the specified shell. This is problematic, because different shells might use different switches for receiving commands. E.g. WSL uses -e, and MinGW-w64 uses something else than -c, too, I just don't know yet what it is. I might need to manualyl call the shell's binary file, making child_process not to make the shell call itself. More manual work, but should allow better customisation on what parameters the shell is presented with. This could allow letting users define custom parameters in settings that will be passed to the shell.

I'll try to find solutions to any problems I'll encounter with these two shells, but this development and testing will take quite a lot of time.

[Taitava]

Some progress, but not a breakthrough yet

I changed the Node.js's child_process.spawn() call not to invoke a shell automatically when a custom shell is used (like I mentioned in the previous comment). Instead of directly executing a user-defined shell command, the call now executes the custom shell binary file, and the user-defined shell command is passed to it via the args parameter of child_process.spawn(). It can launch the shell ok (at least when I tested WSL), but passing the shell command as an argument doesn't work that well.

• On WSL: I can execute single word commands: e.g. pwd work ok and outputs the current working directory*, but echo Hello does not work because it's interpreted as a command as a whole - instead of as a command and an argument. The latter command results in an stderr message saying /bin/bash: echo Hello: command not found and an exit code 127.
• On MinGW-w64: Can't execute anything yet. E.g. pwd results in:
  
  Edit: Now I can execute when I add -c argument before the command (atm. it needs to be done in the plugin's source code, as there's no configuration field for additional shell arguments yet). It even works when the command contains arguments, e.g. echo Hello works.

But I'll continue working on this and come back when there's something more to report. In case there's anyone here wanting to explore this themselves, branch #297-custom-shells is the way to go.

*) Speaking of the working directory, WSL uses correctly the working directory that is defined in the SC plugin's settings. So at least that part works nice and well! 🙂

[Taitava]

A really quick update: I can now execute commands both on MinGW-w64 and WSL. Argument definitions (like -c for MinGW-w64) still need to be done in source code, but otherwise I'm feeling this is starting to rock. 🚀

[Taitava]

Shell arguments can now be defined in the custom shell settings. The most important is {{shell_command_content}} that passes the executable shell command expression to the shell.

I still need to do some smaller improvements (I've got a dozen of uncommitted TODO comments in my source code), write documentation and do more testing.

[Taitava]

Anyone interested in participating in a beta test?

I can do a beta release for this feature some time (cannot give any date, though). I'm really interested to hear feedback about this. My imagination on testing this is very limited. I'm just using WSL and MinGW-w64 myself (both are for Windows). Would be nice to hear how this feature performs with other shells, too, and on other operating systems. Maybe I should test Wine on Linux, too.

If you are interested, comment below. As making a beta release involves some extra work for me, I'm asking you to only volunteer if you can agree to:

• Actually test the feature within a month or two after the beta is released sometime this spring.
• Test for a couple of hours, no need to spend a whole day. Freeform testing, do your own stuff, I don't want to limit your ideas by telling what to test. 😉
• Report back here. Just a message like "Everything seems to work ok for me" is good if you didn't encouter problems.
• I'll be here to answer your questions and suggestions. You can contribute ideas and affect the outcome of this. 👍

[sweenu]

I just tested the beta. And I confirm that it is working fine for my use case of using /bin/sh!
The only thing that could be better is to be able to somehow make the custom shell the default one for every new command.

[Taitava]

Nice to hear that it works well for you! 🙂 You can set the new shell as default for Linux: Environments tab --> Linux default shell setting. Then all shell commands that do not have an explicitly set shell, will use your new custom shell. 🙂

(If the dropdown does not contain your new custom shell, you can close and reopen the settings pane. It should be available in the menu immediately, I'll fix it by the time when this is finally released).

[Taitava]

Documentation is nowhere near complete...

... but I added at least documentation for {{shell_command_content}} variable, that is used in custom shell settings.

[Taitava]

Documentation for custom shell settings: https://publish.obsidian.md/shellcommands/Environments/Custom+shells/Settings+for+custom+shells

[Taitava]

Documentation is ready now

I won't say complete nor finished. Sure there's a lot to improve, but at least this should be a good start.
https://publish.obsidian.md/shellcommands/Environments/Custom+shells/Custom+shells

[Taitava]

BusyBox as a custom shell

Hi @TheRealGramdalf ! 🙂 Would you like to test the SC 0.19.0-beta.1 with BusyBox? You can follow these generic instructions for setting up a custom shell: https://publish.obsidian.md/shellcommands/Environments/Custom+shells/Settings+for+custom+shells

I'd like to get feedback about the custom shell feature, so if you encounter any problems with it, or have ideas on how to improve it, please let me know. 🌞

[Taitava]

Custom shells support is now released

🎉

[seatrout]

To answer my own question — return absolutePath.replace("C:","/mnt/c") But it would be nice if this were in the documents.

[Taitava]

Here you are 🙂
https://publish.obsidian.md/shellcommands/Environments/Custom+shells/Windows+Subsystem+for+Linux+(WSL)#Path+translator

[seatrout]

That's very impressive! Thank you. (somewhere else in the discussions I was ranting about the complications of quoting paths for powershell, and possibly the conclusions I reached then should be in the documentation too)
You've made a really great thing here, though. I don't want to sound ungrateful, or unimpressed.

[Taitava]

Thank you for your feedback! 🌞

I'm open for improvements in the documentation. If you want, you can fork https://github.com/Taitava/obsidian-shellcommands-documentation and edit the documentation pages and create pull requests.

• For example, the variable quoting (aka escaping) has a docummentation page over here: https://publish.obsidian.md/shellcommands/Variables/Escaping+special+characters+in+variable+values
• If you have ideas on how to improve the page (or any other page), I'm glad to receive suggestions. 🙂👍

I do believe that I personally am not the best documentation writer. Users have a better view on what information the documentation is missing that they are looking for. Or what information is there, but is too hard to find or too hard to understand.

Plus, if you make some improvements to the documentation, then you'll probably learn the feature/aspect even better, and you'll also know where to find that information again if you forget it. 😉

[seatrout]

OK. I have forked it and will play.