fish-shell/tests/checks/braces.fish

209 lines
3.7 KiB
Fish
Raw Normal View History

#RUN: %fish %s
echo x-{1}
#CHECK: x-{1}
echo x-{1,2}
#CHECK: x-1 x-2
echo foo-{1,2{3,4}}
#CHECK: foo-1 foo-23 foo-24
echo foo-{} # literal "{}" expands to itself
#CHECK: foo-{}
echo foo-{{},{}} # the inner "{}" expand to themselves, the outer pair expands normally.
#CHECK: foo-{} foo-{}
echo foo-{{a},{}} # also works with something in the braces.
#CHECK: foo-{a} foo-{}
echo foo-{""} # still expands to foo-{}
#CHECK: foo-{}
echo foo-{$undefinedvar} # still expands to nothing
#CHECK:
echo foo-{,,,} # four empty items in the braces.
#CHECK: foo- foo- foo- foo-
echo foo-{,\,,} # an empty item, a "," and an empty item.
#CHECK: foo- foo-, foo-
echo .{ foo bar }. # see 6564
#CHECK: .{ foo bar }.
# whitespace within entries is retained
for foo in {a, hello
wo rld }
echo \'$foo\'
end
# CHECK: 'a'
# CHECK: 'hello
# CHECK: wo rld'
for foo in {hello
world}
echo \'$foo\'
end
#CHECK: '{hello
#CHECK: world}'
echo {a(echo ,)b}
#CHECK: {a,b}
Allow { } for command grouping, like begin / end For compound commands we already have begin/end but > it is long, which it is not convenient for the command line > it is different than {} which shell users have been using for >50 years The difference from {} can break muscle memory and add extra steps when I'm trying to write simple commands that work in any shell. Fix that by embracing the traditional style too. --- Since { and } have always been special syntax in fish, we can also allow { } { echo } which I find intuitive even without having used a shell that supports this (like zsh. The downside is that this doesn't work in some other shells. The upside is in aesthetics and convenience (this is for interactive use). Not completely sure about this. --- This implementation adds a hack to the tokenizer: '{' is usually a brace expansion. Make it compound command when in command position (not something the tokenizer would normally know). We need to disable this when parsing a freestanding argument lists (in "complete somecmd -a "{true,false}"). It's not really clear what "read -t" should do. For now, keep the existing behavior (don't parse compound statements). Add another hack to increase backwards compatibility: parse something like "{ foo }" as brace statement only if it has a space after the opening brace. This style is less likely to be used for brace expansion. Perhaps we can change this in future (I'll make a PR). Use separate terminal token types for braces; we could make the left brace an ordinary string token but since string tokens undergo unescaping during expansion etc., every such place would need to know whether it's dealing with a command or an argument. Certainly possible but it seems simpler (especially for tab-completions) to strip braces in the parser. We could change this. --- In future we could allow the following alternative syntax (which is invalid today). if true { } if true; { } Closes #10895 Closes #10898
2024-11-21 15:55:45 +08:00
e{cho,cho,cho}
# CHECK: echo echo
## Compound commands
{ echo compound; echo command; }
# CHECK: compound
# CHECK: command
{;echo -n start with\ ; echo semi; }
# CHECK: start with semi
{ echo no semi }
# CHECK: no semi
# Ambiguous cases
Allow { } for command grouping, like begin / end For compound commands we already have begin/end but > it is long, which it is not convenient for the command line > it is different than {} which shell users have been using for >50 years The difference from {} can break muscle memory and add extra steps when I'm trying to write simple commands that work in any shell. Fix that by embracing the traditional style too. --- Since { and } have always been special syntax in fish, we can also allow { } { echo } which I find intuitive even without having used a shell that supports this (like zsh. The downside is that this doesn't work in some other shells. The upside is in aesthetics and convenience (this is for interactive use). Not completely sure about this. --- This implementation adds a hack to the tokenizer: '{' is usually a brace expansion. Make it compound command when in command position (not something the tokenizer would normally know). We need to disable this when parsing a freestanding argument lists (in "complete somecmd -a "{true,false}"). It's not really clear what "read -t" should do. For now, keep the existing behavior (don't parse compound statements). Add another hack to increase backwards compatibility: parse something like "{ foo }" as brace statement only if it has a space after the opening brace. This style is less likely to be used for brace expansion. Perhaps we can change this in future (I'll make a PR). Use separate terminal token types for braces; we could make the left brace an ordinary string token but since string tokens undergo unescaping during expansion etc., every such place would need to know whether it's dealing with a command or an argument. Certainly possible but it seems simpler (especially for tab-completions) to strip braces in the parser. We could change this. --- In future we could allow the following alternative syntax (which is invalid today). if true { } if true; { } Closes #10895 Closes #10898
2024-11-21 15:55:45 +08:00
{ echo ,comma;}
# CHECK: ,comma
PATH= {echo no space}
# CHECKERR: fish: Unknown command: '{echo no space}'
# CHECKERR: {{.*}}/braces.fish (line {{\d+}}):
# CHECKERR: PATH= {echo no space}
# CHECKERR: ^~~~~~~~~~~~~~^
Allow { } for command grouping, like begin / end For compound commands we already have begin/end but > it is long, which it is not convenient for the command line > it is different than {} which shell users have been using for >50 years The difference from {} can break muscle memory and add extra steps when I'm trying to write simple commands that work in any shell. Fix that by embracing the traditional style too. --- Since { and } have always been special syntax in fish, we can also allow { } { echo } which I find intuitive even without having used a shell that supports this (like zsh. The downside is that this doesn't work in some other shells. The upside is in aesthetics and convenience (this is for interactive use). Not completely sure about this. --- This implementation adds a hack to the tokenizer: '{' is usually a brace expansion. Make it compound command when in command position (not something the tokenizer would normally know). We need to disable this when parsing a freestanding argument lists (in "complete somecmd -a "{true,false}"). It's not really clear what "read -t" should do. For now, keep the existing behavior (don't parse compound statements). Add another hack to increase backwards compatibility: parse something like "{ foo }" as brace statement only if it has a space after the opening brace. This style is less likely to be used for brace expansion. Perhaps we can change this in future (I'll make a PR). Use separate terminal token types for braces; we could make the left brace an ordinary string token but since string tokens undergo unescaping during expansion etc., every such place would need to know whether it's dealing with a command or an argument. Certainly possible but it seems simpler (especially for tab-completions) to strip braces in the parser. We could change this. --- In future we could allow the following alternative syntax (which is invalid today). if true { } if true; { } Closes #10895 Closes #10898
2024-11-21 15:55:45 +08:00
PATH= {echo comma, no space;}
# CHECKERR: fish: Unknown command: 'echo comma'
Allow { } for command grouping, like begin / end For compound commands we already have begin/end but > it is long, which it is not convenient for the command line > it is different than {} which shell users have been using for >50 years The difference from {} can break muscle memory and add extra steps when I'm trying to write simple commands that work in any shell. Fix that by embracing the traditional style too. --- Since { and } have always been special syntax in fish, we can also allow { } { echo } which I find intuitive even without having used a shell that supports this (like zsh. The downside is that this doesn't work in some other shells. The upside is in aesthetics and convenience (this is for interactive use). Not completely sure about this. --- This implementation adds a hack to the tokenizer: '{' is usually a brace expansion. Make it compound command when in command position (not something the tokenizer would normally know). We need to disable this when parsing a freestanding argument lists (in "complete somecmd -a "{true,false}"). It's not really clear what "read -t" should do. For now, keep the existing behavior (don't parse compound statements). Add another hack to increase backwards compatibility: parse something like "{ foo }" as brace statement only if it has a space after the opening brace. This style is less likely to be used for brace expansion. Perhaps we can change this in future (I'll make a PR). Use separate terminal token types for braces; we could make the left brace an ordinary string token but since string tokens undergo unescaping during expansion etc., every such place would need to know whether it's dealing with a command or an argument. Certainly possible but it seems simpler (especially for tab-completions) to strip braces in the parser. We could change this. --- In future we could allow the following alternative syntax (which is invalid today). if true { } if true; { } Closes #10895 Closes #10898
2024-11-21 15:55:45 +08:00
# CHECKERR: {{.*}}/braces.fish (line {{\d+}}):
# CHECKERR: PATH= {echo comma, no space;}
# CHECKERR: ^~~~~~~~~~~~~~~~~~~~~~^
Allow { } for command grouping, like begin / end For compound commands we already have begin/end but > it is long, which it is not convenient for the command line > it is different than {} which shell users have been using for >50 years The difference from {} can break muscle memory and add extra steps when I'm trying to write simple commands that work in any shell. Fix that by embracing the traditional style too. --- Since { and } have always been special syntax in fish, we can also allow { } { echo } which I find intuitive even without having used a shell that supports this (like zsh. The downside is that this doesn't work in some other shells. The upside is in aesthetics and convenience (this is for interactive use). Not completely sure about this. --- This implementation adds a hack to the tokenizer: '{' is usually a brace expansion. Make it compound command when in command position (not something the tokenizer would normally know). We need to disable this when parsing a freestanding argument lists (in "complete somecmd -a "{true,false}"). It's not really clear what "read -t" should do. For now, keep the existing behavior (don't parse compound statements). Add another hack to increase backwards compatibility: parse something like "{ foo }" as brace statement only if it has a space after the opening brace. This style is less likely to be used for brace expansion. Perhaps we can change this in future (I'll make a PR). Use separate terminal token types for braces; we could make the left brace an ordinary string token but since string tokens undergo unescaping during expansion etc., every such place would need to know whether it's dealing with a command or an argument. Certainly possible but it seems simpler (especially for tab-completions) to strip braces in the parser. We could change this. --- In future we could allow the following alternative syntax (which is invalid today). if true { } if true; { } Closes #10895 Closes #10898
2024-11-21 15:55:45 +08:00
# Ambiguous case with no space
{echo,hello}
# CHECK: hello
Allow { } for command grouping, like begin / end For compound commands we already have begin/end but > it is long, which it is not convenient for the command line > it is different than {} which shell users have been using for >50 years The difference from {} can break muscle memory and add extra steps when I'm trying to write simple commands that work in any shell. Fix that by embracing the traditional style too. --- Since { and } have always been special syntax in fish, we can also allow { } { echo } which I find intuitive even without having used a shell that supports this (like zsh. The downside is that this doesn't work in some other shells. The upside is in aesthetics and convenience (this is for interactive use). Not completely sure about this. --- This implementation adds a hack to the tokenizer: '{' is usually a brace expansion. Make it compound command when in command position (not something the tokenizer would normally know). We need to disable this when parsing a freestanding argument lists (in "complete somecmd -a "{true,false}"). It's not really clear what "read -t" should do. For now, keep the existing behavior (don't parse compound statements). Add another hack to increase backwards compatibility: parse something like "{ foo }" as brace statement only if it has a space after the opening brace. This style is less likely to be used for brace expansion. Perhaps we can change this in future (I'll make a PR). Use separate terminal token types for braces; we could make the left brace an ordinary string token but since string tokens undergo unescaping during expansion etc., every such place would need to know whether it's dealing with a command or an argument. Certainly possible but it seems simpler (especially for tab-completions) to strip braces in the parser. We could change this. --- In future we could allow the following alternative syntax (which is invalid today). if true { } if true; { } Closes #10895 Closes #10898
2024-11-21 15:55:45 +08:00
# Trailing tokens
set -l fish (status fish-path)
$fish -c '{ :; } true'
# CHECKERR: fish: '}' does not take arguments. Did you forget a ';'?
# CHECKERR: { :; } true
# CHECKERR: ^~~^
; { echo semi; }
# CHECK: semi
a=b { echo $a; }
# CHECK: b
time { :; }
# CHECKERR:
# CHECKERR: {{_+}}
# CHECKERR: Executed in {{.*}}
# CHECKERR: usr time {{.*}}
# CHECKERR: sys time {{.*}}
true & { echo background; }
# CHECK: background
true && { echo conjunction; }
# CHECK: conjunction
true; and { echo and; }
# CHECK: and
true | { echo pipe; }
# CHECK: pipe
true 2>| { echo stderrpipe; }
# CHECK: stderrpipe
false || { echo disjunction; }
# CHECK: disjunction
false; or { echo or; }
# CHECK: or
begin { echo begin }
end
# CHECK: begin
not { false; true }
echo $status
# CHECK: 1
! { false }
echo $status
# CHECK: 0
if { set -l a true; $a && true }
echo if-true
end
# CHECK: if-true
{
set -l condition true
while $condition
{
echo while
set condition false
}
end
}
# CHECK: while
{ { echo inner}
Allow { } for command grouping, like begin / end For compound commands we already have begin/end but > it is long, which it is not convenient for the command line > it is different than {} which shell users have been using for >50 years The difference from {} can break muscle memory and add extra steps when I'm trying to write simple commands that work in any shell. Fix that by embracing the traditional style too. --- Since { and } have always been special syntax in fish, we can also allow { } { echo } which I find intuitive even without having used a shell that supports this (like zsh. The downside is that this doesn't work in some other shells. The upside is in aesthetics and convenience (this is for interactive use). Not completely sure about this. --- This implementation adds a hack to the tokenizer: '{' is usually a brace expansion. Make it compound command when in command position (not something the tokenizer would normally know). We need to disable this when parsing a freestanding argument lists (in "complete somecmd -a "{true,false}"). It's not really clear what "read -t" should do. For now, keep the existing behavior (don't parse compound statements). Add another hack to increase backwards compatibility: parse something like "{ foo }" as brace statement only if it has a space after the opening brace. This style is less likely to be used for brace expansion. Perhaps we can change this in future (I'll make a PR). Use separate terminal token types for braces; we could make the left brace an ordinary string token but since string tokens undergo unescaping during expansion etc., every such place would need to know whether it's dealing with a command or an argument. Certainly possible but it seems simpler (especially for tab-completions) to strip braces in the parser. We could change this. --- In future we could allow the following alternative syntax (which is invalid today). if true { } if true; { } Closes #10895 Closes #10898
2024-11-21 15:55:45 +08:00
echo outer}
# CHECK: inner
# CHECK: outer
{
echo leading blank lines
}
# CHECK: leading blank lines
complete foo -a '123 456'
complete -C 'foo {' | sed 1q
# CHECK: {{\{.*}}
complete -C '{'
echo nothing
# CHECK: nothing
Allow { } for command grouping, like begin / end For compound commands we already have begin/end but > it is long, which it is not convenient for the command line > it is different than {} which shell users have been using for >50 years The difference from {} can break muscle memory and add extra steps when I'm trying to write simple commands that work in any shell. Fix that by embracing the traditional style too. --- Since { and } have always been special syntax in fish, we can also allow { } { echo } which I find intuitive even without having used a shell that supports this (like zsh. The downside is that this doesn't work in some other shells. The upside is in aesthetics and convenience (this is for interactive use). Not completely sure about this. --- This implementation adds a hack to the tokenizer: '{' is usually a brace expansion. Make it compound command when in command position (not something the tokenizer would normally know). We need to disable this when parsing a freestanding argument lists (in "complete somecmd -a "{true,false}"). It's not really clear what "read -t" should do. For now, keep the existing behavior (don't parse compound statements). Add another hack to increase backwards compatibility: parse something like "{ foo }" as brace statement only if it has a space after the opening brace. This style is less likely to be used for brace expansion. Perhaps we can change this in future (I'll make a PR). Use separate terminal token types for braces; we could make the left brace an ordinary string token but since string tokens undergo unescaping during expansion etc., every such place would need to know whether it's dealing with a command or an argument. Certainly possible but it seems simpler (especially for tab-completions) to strip braces in the parser. We could change this. --- In future we could allow the following alternative syntax (which is invalid today). if true { } if true; { } Closes #10895 Closes #10898
2024-11-21 15:55:45 +08:00
complete -C '{ ' | grep ^if\t
# CHECK: if{{\t}}Evaluate block if condition is true
$fish -c '{'
# CHECKERR: fish: Expected a '}', but found end of the input
PATH= "{"
# CHECKERR: fish: Unknown command: '{'
# CHECKERR: {{.*}}/braces.fish (line {{\d+}}):
# CHECKERR: PATH= "{"
# CHECKERR: ^~^
$fish -c 'builtin {'
# CHECKERR: fish: Expected end of the statement, but found a '{'
# CHECKERR: builtin {
# CHECKERR: ^
Allow { } for command grouping, like begin / end For compound commands we already have begin/end but > it is long, which it is not convenient for the command line > it is different than {} which shell users have been using for >50 years The difference from {} can break muscle memory and add extra steps when I'm trying to write simple commands that work in any shell. Fix that by embracing the traditional style too. --- Since { and } have always been special syntax in fish, we can also allow { } { echo } which I find intuitive even without having used a shell that supports this (like zsh. The downside is that this doesn't work in some other shells. The upside is in aesthetics and convenience (this is for interactive use). Not completely sure about this. --- This implementation adds a hack to the tokenizer: '{' is usually a brace expansion. Make it compound command when in command position (not something the tokenizer would normally know). We need to disable this when parsing a freestanding argument lists (in "complete somecmd -a "{true,false}"). It's not really clear what "read -t" should do. For now, keep the existing behavior (don't parse compound statements). Add another hack to increase backwards compatibility: parse something like "{ foo }" as brace statement only if it has a space after the opening brace. This style is less likely to be used for brace expansion. Perhaps we can change this in future (I'll make a PR). Use separate terminal token types for braces; we could make the left brace an ordinary string token but since string tokens undergo unescaping during expansion etc., every such place would need to know whether it's dealing with a command or an argument. Certainly possible but it seems simpler (especially for tab-completions) to strip braces in the parser. We could change this. --- In future we could allow the following alternative syntax (which is invalid today). if true { } if true; { } Closes #10895 Closes #10898
2024-11-21 15:55:45 +08:00
$fish -c 'command {'
# CHECKERR: fish: Expected end of the statement, but found a '{'
# CHECKERR: command {
# CHECKERR: ^
$fish -c 'exec {'
# CHECKERR: fish: Expected end of the statement, but found a '{'
# CHECKERR: exec {
# CHECKERR: ^
$fish -c 'begin; }'
# CHECKERR: fish: Unexpected '}' for unopened brace
# CHECKERR: begin; }
# CHECKERR: ^