# Demonstration of shell handler accepting arguments

The current shell handler in Web Origami allows passing an argument to a `.sh` file which will be passed to the child process' stdin. Here, we demonstrate how the shell handler could also take arguments and pass those to the child process.

## stdin approach: pipe allfiles.sh to pubfiles.sh

```
allfiles.sh   #select all markdown files
pubfiles.sh   #select all files with `_pub` in name
```

shell: `sh allfiles.sh | sh pubfiles.sh`

ori cli: `ori "pubfiles.sh(allfiles.sh())"`

site.ori:

```
{
  allfiles: allfiles.sh()
  pubfiles: pubfiles.sh(allfiles)
}
```


## argument approach: pass pattern to match as argument

```
select.sh  PATT  #select files with PATT in name
```

shell: `sh select.sh "_pub"`

ori cli: `ori "select.sh(null, '_pub')"`

site.ori:

```
{
  selectedfiles: pubfiles.sh(null, '_pub')
}
```

### Modified `sh_handler.js`
To make this possible, I use a local modified version of the [distribution `sh_handler.js`](https://github.com/WebOrigami/origami/blob/main/language/src/handlers/sh_handler.js) in this directory. It accepts optional further arguments after the first inputText argument. If these are present, they will be passed as additional arguments in the shell invocation. Hence, you can use both stdin and arguments, and if you do _not_ want to use stdin, you need to pass `null` as the first argument.


## Discussion
I'm not actually sure there's a compelling need to make shell scripts parameterizable in Origami land. Origami projects are often things like websites, where it makes sense to hard-code a lot of config. You don't reuse the project source to generate lots of different outputs. Hence readability is more important than reusability of code. And where you do need to call a similar script with different parameters, usually such scripts will be short enough that you can do the parameterization in Origami land, and call multiple one-liner scripts as needed.

Theoretically, it might be nice to be able to pass arguments to a script which represents a call to a more complex, opaque data source. Maybe when a you have a tree containing data references, not the data itself, and you need to pass the tree value (the data reference) to repeated calls to a script in a `Tree.map()`. For example: the tree contains names of image files, and you want to run image processing on each of those files.

Is that the kind of project, though, that you'd be likely to use Origami for? In short, I don't really have a compelling case, but having this option would allow more experimentation.