Say I am running some command and redirecting its output to a log file with relative path. Three different examples:
sh script.sh > logs/script1.log./script2.sh &> logs/script2.log./script3.sh input.txt > output.txt 2>logs/script3.err
While is necessary to prefix script2.sh and script3.sh with ./ since the executable scripts are in the same directory but not in ${PATH}, is it ever necessary (or preferable) to prefix the paths of the data files, whether input or output? If so, then the same three examples above would become:
sh ./script.sh > ./logs/script1.log./script2.sh &> ./logs/script2.log./script3.sh ./input.txt > ./output.txt 2>./logs/script3.err
In my testing the result is the same, but is it always so? Perhaps there would be a difference when symlinks are used ... I am not sure, hence this question.
I am working with code which sometimes includes ./ in front of the relative data (logs are data too) file paths and sometimes does not. There is no consensus among the team on the best practice and I would like to establish one. If ./ never matters in front of the relative data (as opposed to executable) file paths, then I'd prefer to never use it with non-executable file paths and if it sometimes makes a difference, then I suppose I should always prefix relative non-executable file paths with the ./
What is the best approach?
Is there authoritative documentation for this by any chance?
./prefix will only be needed for executable file when.is not in$PATH(as should be the rule). prefixing date or log file with./is a matter of taste IMHO. – Archemar Apr 21 '21 at 07:12-input.txtinstead ofinput.txtthen./script3.sh ./-input.txtwould be safer in general. Compare: double dash. Here the whole thing totally depends on howscript3.shparses/uses command line arguments and if it expects options (e.g.-i) like many tools do. – Kamil Maciorowski Apr 21 '21 at 08:03