Some questions like Significant Whitespace disallowed string literals. But what are string literals exactly? If I interpret this literally, almost everything in Bash or Tcl are string literals. For example, this program in Bash:
echo -n "Hello World!"
is the same as:
"echo" "-n" "Hello World!"
Similarly in Tcl:
puts -nonewline "Hello World!"
is the same as
"puts" "-nonewline" "Hello World!"
"Hello World!") are all string literals. Even if someone uses only variables like
$a in Tcl, arguably it is still something like
"$a" in PHP, which is a string literal.
But it seemed those answers are acceptable by the community. In that case what are disallowed in a Bash or Tcl answer exactly?
- Commands, options, variable names, and anything else that isn't used as strings by the command.
dateformats, which are options but sometimes also considered strings.
- Bash aliases, such as
alias a="do something", or trap commands, etc.
- Tcl control structures, such as
if 1 "do something".
- String concatenations, such as
c=$a$bin Bash, or
- Concatenations that are arguably not of strings, such as
$a$bin Bash. if
$bcontains spaces, the result will be not only one string.
- Empty strings, such as
- Unused strings, such as the
alias wc=:; wc -c.
I tried to write a shorter one after seeing the Bash answer. But it had alias, printf and even a
\n. I thought the
\n must disqualified it to be a valid answer. But then I found it hard to tell what answers are acceptable. I also remembered another question with a rule about string literals (but I didn't find it). So I was asking here.
The problem I was thinking was, the rule about string literals are usually just for preventing some trivial solutions. If we require the OP define it accurately like what I have listed per question, it will probably become too complex.
But now it turns out to be just "strings with quote", and I think there probably won't be a general rule like this because it may be very unfair in some challenges. Asking the OP should be the right way.