On 7/6/24 22:43, Coutinho de Souza wrote:
> ~autumnull, fs::next now may return an error. The error handling I've
> applied to such case is to print the human readable string for the
> fs::error and exit with the error code 1.
> 
> If that's not how it should be handled, let me know and I'll change the
> patch accordingly.

This is great thanks, patch pushed

~Autumn

On 10 May 2024 23:03:28 BST, Coutinho de Souza <srht-n2c9ebas@onemoresuza.com> wrote:
>As of now, the only way to avoid the default environment variables is by
>setting them to another value. However, there are some cases in which
>the variable being unset is desirable.

can't you just use unset(1) ? it's in posix shell
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#unset>

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

> 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

Actually now that I'm back at my computer I've applied the patch and it 
seems to pass all the tests just fine (after a small unrelated change).

Thanks

~Autumn

>Any ideas where I could go looking around to find its cause?
>
thanks for pointing it out. this is almost certainly due to a change in the fmt:: format string syntax. i'm away from my computer at the minute but i would start looking at updating the uses of fmt:: functions.

~A

Thanks

~Autumn

> I had to export a corrected PATH to get ./bootstrap.sh install to work[0]. I
> am not sure if that is an issue in the bootstrap script.
> 
> [0]: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/55929/diffs#7a4796522f9fb4de4542e829a82eee0b86bf84dd_25_24
Interesting. I'm not sure why that is. If you change line 6 of 
bootstrap.sh from "bin:$PATH" to "$PWD/bin:$PATH" does that help? If so 
I can change that upstream.

I suppose it's not the end of the world either way.

~Autumn

> I've being playing around with `haredo` and being finding it awesome!
Nice, thanks for saying so :)

> I was wondering the following:
> 
> 1. Would there be any other way of achieving this variables sharing?
The way you've listed is the best way I know of. Since the environment 
variables carry down to child processes, you can get away with just 
sourcing env.sh in the .do files that you intend to call as top-level 
targets, but that's the only improvement.

> 2. Should I be thinking differently on how to work with haredo? Perhaps
>     this sharing could be replaced with a more idiomatic construction?
> 

I've now pushed 1.0.4 tag, lmk if any problems.

~Autumn