Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add SPECS.md #2

Open
CohenArthur opened this issue Oct 15, 2020 · 9 comments
Open

Add SPECS.md #2

CohenArthur opened this issue Oct 15, 2020 · 9 comments
Labels
enhancement New feature or request spec Issue regarding the shell's specification

Comments

@CohenArthur
Copy link
Member

Refine it enough so that it is readable and understanble. The specs will of course evolve through the project, but they need to be here as a starting point.

@CohenArthur CohenArthur added enhancement New feature or request spec Issue regarding the shell's specification labels Oct 15, 2020
@n1tram1
Copy link
Contributor

n1tram1 commented Oct 16, 2020

@n1tram1
Copy link
Contributor

n1tram1 commented Oct 16, 2020

Any comments ?

@CohenArthur
Copy link
Member Author

I agree with that, but we need to decide what we categorize as bullshit :D

@n1tram1
Copy link
Contributor

n1tram1 commented Oct 16, 2020

  • HERE-Docs

I can't think of other things now. Any ideas @Skallwar @CohenArthur @08a ?

@Skallwar
Copy link
Contributor

  • Arithmetic

@n1tram1
Copy link
Contributor

n1tram1 commented Oct 16, 2020

I believe a needed feature is JITing shell, that way we will have a very fast shell.

@CohenArthur
Copy link
Member Author

CohenArthur commented Oct 16, 2020

If we agree that not executing existing POSIX scripts is okay, then I can think of a few:

  • No single quote quoting, only double quote, because it is confusing, unsound, and annoying to implement
  • No here-docs

The requirement that double-quotes be matched inside "${...}" within double-quotes and the rule for finding the matching '}' in XCU Parameter Expansion eliminate several subtle inconsistencies in expansion for historical shells in rare cases; for example:

"${foo-bar"}

yields bar when foo is not defined, and is an invalid substitution when foo is defined, in many historical shells. The differences in processing the "${...}" form have led to inconsistencies between historical systems. A consequence of this rule is that single-quotes cannot be used to quote the '}' within "${...}"; for example:

unset bar
foo="${bar-'}'}"

is invalid because the "${...}" substitution contains an unpaired unescaped single-quote. The can be used to escape the '}' in this example to achieve the desired result:

unset bar
foo="${bar-}}"

The differences in processing the "${...}" form have led to inconsistencies between the historical System V shell, BSD, and KornShells, and the text in the Shell and Utilities volume of POSIX.1-2017 is an attempt to converge them without breaking too many applications. The only alternative to this compromise between shells would be to make the behavior unspecified whenever the literal characters single-quote, '{', '}', and '' appear within "${...}". To write a portable script that uses these values, a user would have to assign variables; for example:

squote=' dquote=" lbrace='{' rbrace='}'
${foo-$squote$rbrace$squote}

None of this ^ complex variable expansion crap

  • $ alias while="/" has to be removed. Aliasing reserved keywords has to be forbidden
  • No IFS
  • No variable/arithmetic expansion other than string formatting and binary usage. I don't want my shell to take care of regexes and substring finding and whatnot
  • ~ should be simple. It should only expand to the home directory. No ~!, ~-, ~whatever
  • No switch cases, or not in this form. They suck.
  • Less ambiguity overall
  • No ugly regex/pattern matching rules, only simple globbing

I'd basically like to vote out anything that isn't crystal clear or that does not make sense in the spec.

@CohenArthur
Copy link
Member Author

I believe a needed feature is JITing shell, that way we will have a very fast shell.

Once we have a shell we can talk about JITting it :D

@n1tram1
Copy link
Contributor

n1tram1 commented Oct 16, 2020

$ alias while="/" has to be removed. Aliasing reserved keywords has to be forbidden

this is actually easy to implement now that I understand how to write a shell

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request spec Issue regarding the shell's specification
Projects
None yet
Development

No branches or pull requests

3 participants