Troubleshooting

A: You should not use your main password. You need a separate password for the labs, you can set it:

1. by using the following credential pair at the lab computer (username/password): problem/login. The computer should reboot and display a web browser (use Ctrl+Q for terminating the session).
2. using the following link: https://cw.felk.cvut.cz/password/ Note: You will need the main access password (that one used for the study information system (KOS)).

A: Make sure you can connect to the server, i.e.:

• Check your internet connection
• Verify that the file-server is ON (ping 147.32.84.128)
• Use correct syntax: ssh user@147.32.84.128
• Make sure you use the correct password (use the one you use for logging-in in the lab, see above). Note: Make sure you provide your own username.

A: Use your backed-up version. Only the files in your home directory are maintained (/home.nfs/username). These are accessible via any of the lab computer. Note that:

• Data in temporary locations (/tmp, /local/temporary) are deleted daily.
• Data saved on a disk of a local machine might be accessible by logging-into the target machine. Not guaranteed and not recommended.
• It's up to you to backup your data.

A: Make sure

• Your script is executable (has correct permissions, see chmod)
• The header (shebang) is correct (#!/bin/bash)
• You use the correct path of executing the script: ./script.sh, or you've added the directory (where the script is located) to your PATH environment variable
• The script was not modified during transfer (less ./script.sh), or the CR/LF line endings are correct (Note: Linux uses only LF, Windows use CR/LF. Use Google or take a look at stackoverflow.com discussion.
• See also basic information for creating a BASH script.

A: You probably use the following redirection: echo “ERROR” > /dev/stderr

• In such case this is executed as a redirection to a file (with creation/truncation).
• A bit better solution is to use: echo “ERROR” » /dev/stderr
• But I prefer simpler solution: echo “ERROR” >&2

A: Ok, you need to understand the motivation that led us to use the Automated Evaluation: The Automated Evaluation (AE) is only a part of the process of teaching you how to create develop a program according to the client specification (and to simulate a nearly-real-world scenario). We try to maintain an industry-level requirements for a good programming style:

• The specification is never complete¹⁾. Make your best effort to guess/think (or even show some creativity/enhancement)²⁾.
• Read the specification multiple times, make sure you understand the main idea of the task. Remember to create a list (i.e. by underlining) of important technical details (what should go to stderr, what strings should be output, …).
• Design, develop and test the code on your own. Think about it, redesign (refactor) it when needed. Make it readable and elegant³⁾.
• Verify that it conforms to the specification given.
• The client (in real world) only occasionally provides you with some testing software you can test your code with. Therefore, make your best effort and handle all possible exceptions (incorrect input, non-existing file, incorrect permissions, …). Do not try to satisfy the AutomatedEvaluation system only⁴⁾.
• After you have created your 'best' solution, you should try if it passes the Automated evaluation. If it does not pass, it's probable that you have made a mistake in your code (or in understanding the specification). However, if your code was near-correct, these modifications shall be minor. If not, there is an error out there…
• Of course, even AutomatedEvaluation system is undergoing changes. It's therefore possible that it also contains errors. Verify with your teacher and report the bug. If you are lucky you might get some +points for activity.