---
feature_story: FS_92_75_93_01
feature_title: clean command line
feature_status: TODO
---

# Problem statement

If `ARGRELAY_DEBUG` is defined, it is possible to observe what command line argrelay client receives:

```sh
export ARGRELAY_DEBUG="p"
```

Consider few cases:

1.  Command line with comment:

    ```sh
    relay_demo some_arg # comment
    ```

2.  Command line with piped command:

    ```sh
    relay_demo some_arg | cat
    ```

3.  Command line with sub-shell:

    ```sh
    echo $( relay_demo some_arg )
    ```

There is a difference how clean command line of unrelated chars is (depending on the action):

*   `ServerAction.DescribeLineArgs`

    This action has the dirtiest command line (Bash simply sends entire command line string):

    1.
    ```
    "relay_demo some_arg # comment" cursor_cpos: 19 comp_type: 94
    ```

    2.
    ```
    "relay_demo some_arg | cat" cursor_cpos: 19 comp_type: 94
    ```

    3.
    ```
    "echo $( relay_demo some_arg )" cursor_cpos: 27 comp_type: 94
    ```

*   `ServerAction.ProposeArgValues`

    This action is relatively safe from mis-interpretation, however, comments (after `#`) may still affect the results.

    1.
    ```
    "relay_demo some_arg # comment" cursor_cpos: 19 comp_type: 33
    ```

    2.
    ```
    "relay_demo some_arg " cursor_cpos: 19 comp_type: 33
    ```

    3.  Bash does not invoke completion for command in sub-shell expression.


*   `ServerAction.RelayLineArgs`

    This is the cleanest action.<br/>
    This is largely because the line is actually parsed by Bash first.<br/>
    Then, all args (passed by Bash) related to the command in question are simply concatenated on the client side.

    1.
    ```
    "relay_demo some_arg" cursor_cpos: 19 comp_type: 42
    ```

    2.
    ```
    "relay_demo some_arg" cursor_cpos: 19 comp_type: 42
    ```

    3.
    ```
    "relay_demo some_arg" cursor_cpos: 19 comp_type: 42
    ```

The problem is that, depending on the extra chars, the interpretation outcome may become different.

# Bash version

The Bash version test results were obtained for:

```
bash --version
GNU bash, version 5.2.15(1)-release (x86_64-redhat-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
```

# Solution taken

Do nothing at the moment. Parsing Bash command line correctly (as Bash does) is a moving target<br/>
and requires relatively complex implementation (consider quotes for strings, nested sub-shell expressions, etc.).

Accept the limitation:
the functions should be used with clean command line by user for now
(no support from `argrelay` at the moment to process and clean up the command line).

# Possible way forward

Maybe `shlex` can be used for parsing command line (at least for stripping off quotes)?
https://docs.python.org/3/library/shlex.html

But this might be still difficult even for stripping off quotes
because we need to track the cursor position within the command line.

There are also some (relatively old though) disappointments about `shlex`:
https://www.reddit.com/r/learnpython/comments/42kq75/shlex_what_why/

# See also

A comment on the related issue:
https://github.com/argrelay/argrelay/issues/22#issuecomment-1873229478

