As of now, haredo uses the first 3 of the positional arguments of the
shell script, for example, "${3}" for its temporary file.

I've been finding a few shortcomings of this approach:

1. Being unable to have a `run.do` file, if it would take any arguments.
   Imagine something like this:

   ```sh
   haredo bin/name

   ./bin/name "${@}"
   ```

   When the positional arguments would have being passed to the `haredo`
   invocation.

2. Being unable to overwrite the positional arguments array --- "${@}"
   --- outside of functions, which is the only way of ensuring that some
   output is correctly escaped on POSIX, since there are no arrays like
   in Bash.

So I ask: is the design of using the positional arguments directly here
to stay?

Because if not, the values on "${1}", "${2}" and "${3}" could have the
same treatment as the defined environment variables[1], like `${HARE}`
or `${CC}`, that is, they could be something like `${HAREDO_*}`. "${3}",
for instance, could become `${HAREDO_TMPFILE}`.

I must say that the two cases presented would cause different changes to
`haredo`. For instance, 2 could be achieved by setting "${1}", "${2}"
and "${3}" as environment variables. 1, however, would be more
complicated.

It would need a change of the cli interface: instead of `haredo
[OPTION]... [HAREDO_FILE] ++ [SRCFILES]`, the arguments to the script
would have to be in there, perhaps with an `-a` flag, stating the
everything after it is treated as the positional arguments of the
script.

Would there be any interest in patches providing such changes?


[1]: https://git.sr.ht/~autumnull/haredo/tree/34136cfca3500935643f8c39eca3748047f3a829/item/doc/haredo.1.scd#L83

> 2. Being unable to overwrite the positional arguments array --- "${@}"
>     --- outside of functions, which is the only way of ensuring that some
>     output is correctly escaped on POSIX, since there are no arrays like
>     in Bash.
> 
> So I ask: is the design of using the positional arguments directly here
> to stay?
> 
> Because if not, the values on "${1}", "${2}" and "${3}" could have the
> same treatment as the defined environment variables[1], like `${HARE}`
> or `${CC}`, that is, they could be something like `${HAREDO_*}`. "${3}",
> for instance, could become `${HAREDO_TMPFILE}`.

i don't know enough about posix shell to understand what you're talking 
about with the output escaping, but it sounds a little hacky? the only 
other objection i have here is that the fully qualified $HAREDO_* names 
are a bit cumbersome, but they are clearer, so if the need here is 
really justifiable then maybe i'd consider it.

> It would need a change of the cli interface: instead of `haredo
> [OPTION]... [HAREDO_FILE] ++ [SRCFILES]`, the arguments to the script
> would have to be in there, perhaps with an `-a` flag, stating the
> everything after it is treated as the positional arguments of the
> script.

unfortunately i think this point is a deal breaker for #1, the cli 
interface with -a would become quite ugly. i also think using arbitrary 
arguments is out of scope for haredo, but thanks for putting in the thought.

~Autumn

Using haredo in the meantime, I've realized that there's already a way
to achieve what I was proposing with passing the arguments as
environment variables, by simply doing this: :)

```bash
target="${1}"
basename="${2}"
tmpfile="${3}"
```

And then override the positional arguments of the script.

But perhaps, the used shell could be overridden? By doing so, it would
allow shell specific functionality --- e. g., bash's arrays, ksh's regex
---, while also guarantying which shell is being used, since `sh` is
usually a symlink to another shell.

I think this could be achieved by changing the commands'
preparations[0][1] to `os::tryenv("SHELL", "sh")` instead of a hardcoded
"sh".

Regarding the use of arbitrary arguments, it ain't a big deal at all: Of
the other build frameworks that come to mind --- make and just ---, only
the latter supports and it can easily be replaced with:

```console
[user@hostname: ~] $ haredo <bin-target> && <path-to-binary> \
    <arbitrary-arguments>
```

[0]: https://git.sr.ht/~autumnull/haredo/tree/34136cfca3500935643f8c39eca3748047f3a829/item/src/haredo.ha#L285
[1]: https://git.sr.ht/~autumnull/haredo/tree/34136cfca3500935643f8c39eca3748047f3a829/item/src/haredo.ha#L288

On 1/27/24 00:43, Coutinho de Souza wrote:
> Using haredo in the meantime, I've realized that there's already a way
> to achieve what I was proposing with passing the arguments as
> environment variables, by simply doing this: :)

glad to hear

> But perhaps, the used shell could be overridden? By doing so, it would
> allow shell specific functionality --- e. g., bash's arrays, ksh's regex
> ---, while also guarantying which shell is being used, since `sh` is
> usually a symlink to another shell.

the reason that 'sh' is used is to make the build scripts as portable as 
possible, so that it doesn't rely on non-standard shell behavior

~Autumn