Replace ~ with homedir

[prsabahrami]

As an extension to #37 and fix for #44

[prsabahrami]

At first I thought we can do the replacement while parsing and that way ls ~/Desktop and other commands would work; but, there wouldn't be anyway to handle echo ~user. Hence, reverting parser modification and making the changes on args.rs. This will result in making args mutable.

[certik]

What does echo ~user do? On Ubuntu 22 I get:

[prsabahrami]

What does echo ~user do? On Ubuntu 22 I get:

I believe you should replaceuser with the username. For exampe, in your case, it would be echo ~ondrej. This returns the home dir to a specific user.

[certik]

Ah I see, indeed it does:

I didn't know this is possible. If it is hard to support, I think we don't need to support this.

[prsabahrami]

I don't think it is hard to support. Rather, it makes it impossible to expand ~ to homedir at parsing time. I believe there are other examples too where an unquoted ~ is not directly expanded. Hence, I think what I just implemented, only expands ~ in commands where it should be. With this implementation, we can support echo ~user easily as well.

[wolfv]

Hmm, complicated. I wonder if we should treat it as a special token.

The following behavior is observed in zsh:

╭─wolfv@pixi ~/Programs/shell ‹multiline●› 
╰─$ echo foo~asd 
foo~asd
╭─wolfv@pixi ~/Programs/shell ‹multiline●› 
╰─$ echo ~/foo  
/Users/wolfv/foo
╭─wolfv@pixi ~/Programs/shell ‹multiline●› 
╰─$ echo "~"
~
╭─wolfv@pixi ~/Programs/shell ‹multiline●› 
╰─$ echo ~user
zsh: no such user or named directory: user
╭─wolfv@pixi ~/Programs/shell ‹multiline●› 
╰─$ echo ~wolfv                                                                                                                    
/Users/wolfv

So only when ~ is unquoted and at the beginning of a string it does "something". And the remainder string is parsed until a / is found? (not sure about that last rule).

[wolfv]

PS: I haven't tested your branch yet! So maybe it works already exactly as bash here.

[certik]

I think ls should not be handling ~ explicitly.

[certik]

I think it's time to step back and separate parsing, semantics and execution.

The parser should take care of handling ~ and distinguish if it is part of the token, or special handling. If special handling, it needs to use a dedicated AST node. It should produce an AST.

The semantic phase goes over the AST and checks all semantics (such as: are options valid for "ls", "cd" and other commands).

It should create an IR (intermediate representation) that is semantically valid.

Conceptually we then need to add several IR->IR passes:

• Add IR->IR pass that expands ~ node and other things (variable substitutions, etc.).

The backend then takes the IR and executes. Ideally it does not handle any ~, any variables (unless they are runtime), etc. Everything is prepared.

We then have a choice: either we have an explicit IR->IR passes, or we can merge them with AST->IR, or with IR->backend. However, conceptually (in our head) we should think of these operations as independent, standalone IR->IR passes.

I made this #70.

[prsabahrami]

Hmm, complicated. I wonder if we should treat it as a special token.

The following behavior is observed in zsh:

╭─wolfv@pixi ~/Programs/shell ‹multiline●› 
╰─$ echo foo~asd 
foo~asd
╭─wolfv@pixi ~/Programs/shell ‹multiline●› 
╰─$ echo ~/foo  
/Users/wolfv/foo
╭─wolfv@pixi ~/Programs/shell ‹multiline●› 
╰─$ echo "~"
~
╭─wolfv@pixi ~/Programs/shell ‹multiline●› 
╰─$ echo ~user
zsh: no such user or named directory: user
╭─wolfv@pixi ~/Programs/shell ‹multiline●› 
╰─$ echo ~wolfv                                                                                                                    
/Users/wolfv

So only when ~ is unquoted and at the beginning of a string it does "something". And the remainder string is parsed until a / is found? (not sure about that last rule).

Yes, that is correct.
I think the following gives proper explanation on this.
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_06_01
In regards to the last rule.

Otherwise, the characters in the tilde-prefix following the tilde shall be treated as a possible login name from the user database.

[wolfv]

Ah great, the reference you found is indeed pretty clear :)

[prsabahrami]

I have moved this to draft for now. I will try to expand during parsing just as @certik mentioned.

[wolfv]

I think the pest grammar should turn this into something like TILDE{ username: Option<string> } and then later, we would expand this.

[certik]

I will try to expand during parsing just as @certik mentioned.

I was suggesting NOT to expand during parsing, but rather create a TILDE{ username: Option<string> } AST node for things like ~/bin and ~user, but not for a~b. We expand this later in the compiler.