I find this task:

Find all files in the directory ​ /srv/SAMPLE002​ with a file extension of ​ .tar . Write a list of matching filenames, one per line, to the file /opt/SAMPLE002/toBeCompressed.txt​, which has already been created. Ensure that you specify a relative path to each file, using ​ /srv/SAMPLE001​ as the base directory for the relative path.

I created SAMPLE001 and SAMPLE002 directory in srv. In SAMPLE002 I created 5 files with .tar extension. I have a problem with this part of the task:

Ensure that you specify a relative path to each file, using ​ /srv/SAMPLE001​ as the base directory for the relative path.

I try like this:

 find /srv/SAMPLE001/../SAMPLE002  -type f -name "*.tar"

Is it a good solution for my task? I mean: relative path to each file. Maybe there's a better solution than mine.

  • 1
    The question would be better if you explicitly posted the result from the command you tried. It's not bad as it is, no need to improve after it was answered. In similar cases in the future consider posting the results of your tries along with the tries. Aug 24, 2020 at 14:22

2 Answers 2


No. The paths you get from your command are not relative.

The command does not explicitly specify an action for find, so implicit -print is used. -print prints pathnames. Pathnames are created this way:

[…] Each path operand shall be evaluated unaltered as it was provided, including all trailing characters; all pathnames for other files encountered in the hierarchy shall consist of the concatenation of the current path operand, a <slash> if the current path operand did not end in one, and the filename relative to the path operand. […]

This means if you specify /srv/SAMPLE001/../SAMPLE002 as the only path operand (stating point) then you can only get lines from -print that start with this exact string.

Now check the definition of the relative pathname:

Relative Pathname
A pathname not beginning with a <slash> character.

Anything you can get from your command must start with / (a <slash> character) because the path operand you used starts with /. Then by definitions these pathnames are not relative. The only way to get relative pathnames from find … -print is to provide a relative path operand (starting point).

In your case it can be like this:

cd /srv/SAMPLE001 && find ../SAMPLE002 -type f -name "*.tar"

(&& in case cd fails). Now every pathname must start with ../SAMPLE002. The paths to the .tar files you're after will start with ../SAMPLE002/. By definition they will be relative.

The definition is very terse. To know where the relativeness comes from, one needs to know how *nix resolves paths. If you know this then you will agree that


will point to the same foo.rar, no matter what the current working directory is. But


will depend (rely) on the current working directory. The latter path may or may not point to the right foo.rar, depending on the current working directory. This is the point of being relative. If the current working directory is /srv/SAMPLE001 then the path will point to the right file.

Note if /srv/SAMPLE001/ didn't exist or if /srv/SAMPLE001/.. didn't exist (e.g. SAMPLE001 is a regular file), then /srv/SAMPLE001/../SAMPLE002/foo.rar could not be resolved. This is the only dependence from /srv/SAMPLE001 in this case. The dependence does not make /srv/SAMPLE001/../SAMPLE002/foo.rar a relative path though.

Your original command does not write to /opt/SAMPLE002/toBeCompressed.txt at all. Use a proper operator to redirect the output from find. E.g.:

cd /srv/SAMPLE001 && find ../SAMPLE002 -type f -name "*.tar" >/opt/SAMPLE002/toBeCompressed.txt
  • Hi thanks for answer :) Yes my code does not write to txt file, because i had problem with relative path :)
    – PawelC
    Aug 24, 2020 at 17:18

Please use the below comamnd,

find /srv/SAMPLE002 -type f -name "*.tar" -fprintf /opt/SAMPLE002/toBeCompressed.txt "%P \n"

  • Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Apr 27 at 18:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.