42sh Implementation
At all times, you MUST keep in mind that this is the order of priority of instructions in case of conflicting information:
- The subject
- The SCL
- The behavior of
bash --posix
1. Non-existing Shell Script
What is the expected behavior when trying to parse a command from a shell script which does not exist? For instance:
42sh$ 42sh doesnotexist.sh
Answer:
This will not be tested so you can do whatever you want.
2. Variable Expansions in for Loops
When running the given test, we notice that bash --posix displays "hello world" with one space.
However, our program displays "hello world" with two spaces. Is that due to us not having handled the IFS yet?
Given test:
for a in " hello $@ world "
do
echo $a;
done
Answer:
Before Step 4, you do not handle field splitting, therefore it is normal for the output to differ. Indeed, since
$ais not quoted inecho $a, variable expansion occurs at that point in the program, resulting in one space only withbash --posixthanks to the IFS.
3. Implementation Defined Features
The SCL specifies in rule #1 of cd, regarding the HOME environment variable, that the default
behavior is implementation-defined. What should we do about that?
Section 2.8.2 of the SCL reads:
The exit status of a command that terminated because it received a signal shall be reported as greater than 128.
How can we check that we have the correct exit status?
Answer:
This means that you are free to do whatever you deem best-fitting. These cases will not be tested.
4. "**" Operator in Arithmetic Expansion
It is said that we have to implement the "**" operator. However, it is not POSIX compliant. Do we have implement it regardless?
Answer:
Yes. You can mimic the behavior of
bash --posix.
5. Redirection Grammar Imprecision
For redirections, the grammar does not expect a IONUMBER at the end of the rule:
redirection =
[IONUMBER] ( '>' | '<' | '>>' | '>&' | '<&' | '>|' | '<>' ) WORD
;
Should we not handle cases such as 2>&1? If not, I do not understand the use of <&
when an IONUMBER is not given at the end.
Answer:
Both the subject and the SCL specify a WORD token and NOT an IONUMBER at the end. However, in the case of
>&and<&, if the WORD is neither a valid number nor-, the behavior is not specified (sections 2.7.5 and 2.7.6). Thus, we do not test this.
6. Non-XBD Name Expansion Inconsistency
In a for Loop, when the variable does not correspond to a XBD name such as:
for % in a b c; do echo $%; done;
Should we return an exit code between 1 and 125, inclusive, and halt execution because the error is within the expansion, or should we proceed by displaying 2?
Answer:
In this case,
bash --posixis not compliant with the SCL: the SCL specifies that the for Loop variable must respect XBD for the grammar to be valid. However,bash --posixallows, at parsing, for non-XBD-compliant variables. Thus, the error is only noticed at execution, and only halts execution when--posixis invoked. We will not test this.
7. Redirection Towards Stream
When testing echo toto 1>&- using bash --posix and dash, the SCL's requested behavior is not observed.
Normally, fd 1 (stdout) should be closed. However, if an echo is run after, such as echo tata, tata is displayed on stdout.
Which behavior should we follow?
Answer:
Redirections are only effective in the execution context of the command(s) they are associated with. For this example, fd 1 should be closed when executing
echo toto, then restored. This applies for all types of redirections.
8. Variable Declaration Inconsistency with Builtins
Using bash --posix and dash, the following script
abc=3 . ./non-existing.file
echo $abc
results in:
.: cannot open ./non-existing.file
3
The same script with another builtin does not declare the variable abc:
abc=3 echo test$abc
echo test$abc
results in:
test
test
.
In the SCL, the dot builtin's description does not specify this behavior.
Should we reproduce it or is it an imprecision?
Answer:
dotis aSpecial Built-in Utility. According to rule 2.9.1 of the SCL, if the command to execute is aSpecial Built-in Utility, then the assignment should affect the shell's environment, and not just the command itself. However, this will not be tested. Furthermore,echois described as neither aBuilt-in Utilitynor aSpecial Built-in Utility, but as a simpleUtility. Therefore, every variable assignment linked to the command must remain within the scope of the command itself.