feat: Add shell-style quoting and escaping to edit and run commands

[Mivirl]

Addresses #1314

Allows specifying a custom editor command with quoted spaces

${CRATE_ROOT} and ${GPR_FILE} are still replaced directly, not using parameter expansion.

The argument to alr run -a has been changed to use the same quoting rules as alr edit instead of using the OS-specific rules provided by GNAT.OS_Lib.Argument_String_To_List.

Quoting and token recognition uses the behavior for the shell command language from the POSIX.1-2024 standard with a few changes:

• 2.2.2 Single-Quotes
  • No changes
• 2.2.3 Double-Quotes
  • The dollar-sign is not used for parameter expansion, command substitution, or arithmetic expansion
  • The backquote is not used for command substitution
  • The backslash is an escape character within double quotes only when immediately followed by \ or "
• 2.3 Token Recognition
  • Here-documents are not supported
  • Parameter expansion, command substitution, and arithmetic expansion are not supported
  • Comments are not supported
  • Alias substitution is not supported

PR creation checklist

• A test is included, if required by the changes.
• doc/user-changes.md has been updated, if there are user-visible changes.
• doc/catalog-format-spec.md has been updated, if applicable.
• BREAKING.md has been updated for major changes in alr, minor/major in catalog format.

[mosteo]

A neat improvement. Only, see the comment about the duplicated Spawn_Raw.

[github-actions]

This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[mosteo]

Ideally we would need a Python test for the end-user behavior. @Mivirl, are you able/willing to do it?

[mosteo]

Thanks for the tests, Mivirl. Only minor comments about one of them.

I'm not sure why the Windows test is failing. There's this curious effect where the last 'e' from example is disappearing:

https://github.com/alire-project/alire/actions/runs/18571537329/job/52946369421?pr=1993#step:17:1581

[Mivirl]

Thanks for the feedback!

I'm not sure why the Windows test is failing. There's this curious effect where the last 'e' from example is disappearing:

https://github.com/alire-project/alire/actions/runs/18571537329/job/52946369421?pr=1993#step:17:1581

Not sure why that's happening either. I don't currently have a windows environment ready to debug it, but I'm going to set one up so I can figure it out.

[Seb-MCaw]

By default, Windows GNAT does some postprocessing on command line arguments. I don't know if it's functioning as intended, but the handling of quotes is decidedly weird.

Adding

Do_Argv_Expansion : Integer := 0;
pragma Export (C, Do_Argv_Expansion, "__gnat_do_argv_expansion");

to the declarative part of Echo_Arguments appears to be sufficient to get the test to pass (though I believe this only disables a subset of the postprocessing).

[Mivirl]

By default, Windows GNAT does some postprocessing on command line arguments. I don't know if it's functioning as intended, but the handling of quotes is decidedly weird.

Adding

Do_Argv_Expansion : Integer := 0;
pragma Export (C, Do_Argv_Expansion, "__gnat_do_argv_expansion");

to the declarative part of Echo_Arguments appears to be sufficient to get the test to pass (though I believe this only disables a subset of the postprocessing).

Thanks, that's good to know

Just adding reference links below to a few commits involving this feature as I'm looking into it:

• Add support for wildcard expansion for Unicode parameters on Win32
• Do not expand quoted arguments
• Add weak symbol __gnat_do_argv_expansion
• Current version

[Mivirl]

By default, Windows GNAT does some postprocessing on command line arguments. I don't know if it's functioning as intended, but the handling of quotes is decidedly weird.

Adding

Do_Argv_Expansion : Integer := 0;
pragma Export (C, Do_Argv_Expansion, "__gnat_do_argv_expansion");

to the declarative part of Echo_Arguments appears to be sufficient to get the test to pass (though I believe this only disables a subset of the postprocessing).

Thanks! I've added this to Echo_Arguments, since I think it makes sense to disable for this test.

I've also submitted a bug report for GNAT about the disappearing 'e'.

[mosteo]

Looks good to me. @Seb-MCaw, since you seem familiar with these issues, any final comment?

[Seb-MCaw]

you seem familiar with these issues

Not at all; this is the first time I've encountered this argument expansion behaviour.

The PR looks good to me (except for the very minor detail that origins.archive.download_cmd is not mentioned in the changelogs).

It's fortunate we've run into this, though, since it raises the wider issue of alr performing the same postprocessing:

C:\xxx> python echo_args.py 'Hello \"W\"o\"r\"l\"d\"
'Hello
"W"o"r"l"d"

C:\xxx> alr exec -- python echo_args.py 'Hello \"W\"o\"r\"l\"d\"
Hell
World

I guess this at least needs to be documented somewhere, if not disabled?

---

Edit: On closer inspection, the " effect appears to be a GNAT.OS_Lib.Spawn behaviour, since I still get:

C:\> alr \"W\"o\"r\"l\"d\"
ERROR: Unrecognized command: "W"o"r"l"d"

Nonetheless, this is Windows-only, and isn't mentioned in our documentation as far as I'm aware.

[mosteo]

I guess this at least needs to be documented somewhere, if not disabled?

For the disabling, do you mean with __gnat_do_argv_expansion? Any collateral damage that we may expect from that?

[Seb-MCaw]

For the disabling, do you mean with __gnat_do_argv_expansion?

Yes; that's the only way I'm aware of.

Any collateral damage that we may expect from that?

Obviously this would disable wildcard expansion etc. for all alr commands, and there are no doubt some situations where the current behaviour could potentially be convenient. The only results of a search for __gnat_do_argv_expansion in the GCC sources are the if statements surrounding the wildcard expansion and quote removal logic, so there aren't any other effects which are immediately obvious. I'm really not a toolchain expert, though, so there could definitely be ramifications I'm missing.

[mosteo]

I think we would be better served by not having unsuspected expansions done for us. I suppose this comes from Windows where the shell is not doing the expansion? Frustration noises.