0

UPDATE Once again, I can't post an answer to my question! Clicking the button just triggers an error message: "Unable to load popup - please try again". So, I have no other choice than to share the solution like this:

input_path="`token="0"; if [[ "$input_path" =~ /$ ]]; then token="1"; input_path="${input_path%/}"; fi; cd "${input_path%/*}"; printf "$PWD/"; if [[ "$token" -eq 1 ]]; then printf "${input_path##*/}/"; else printf "${input_path##*/}"; fi`"

Evaluation:

0:1 - bash exhaustion:unix philosophy

If coding thoroughly is an ambition, the bash exhaustion way just proves that in this case it's far better to rely on unix philosophy, here meaning application of tool realpath, instead of replicating what it does with bash - you see, it works, but it's a mess, very complicated and a lot more code.


Use the tool find, from a certain working directory, setting the scope with a relative path, search for any files, and apply -exec realpath - will have the same working directory as find, unless using -execdir - on the resulting matches - relative paths - and output will be that same list of relative paths, but transformed into absolute paths.

Out of curiosity: Can bash do this alone?

1
  • Do what alone, exactly? Can you give us a specific example? Do you need bash to also find the files or just generate the absolute paths after they have been found? And how absolute? Should symbolic links be resolved? Commented May 11, 2024 at 9:14

1 Answer 1

1

pwd -P should do it. The runtime help says:

$ help pwd
pwd: pwd [-LP]
    Print the current working directory.  With the -P option, pwd prints
    the physical directory, without any symbolic links; the -L option
    makes pwd follow symbolic links.

and so:

$ ln -s /usr/bin/ ./foo; cd foo; pwd -P
/usr/bin

If you need to do it for an arbitrary path without changing the working directory of the whole shell, put the cd and pwd in a subshell:

$ (cd somewhere; pwd -P)
2
  • The pwd(1p) is a bit more verbose here, but essentially agrees with the output of help. Commented May 10, 2024 at 20:06
  • (1) I believe that I (at least partly) understand what you’re thinking, but I don’t see it written in your answer.  (2) I find the question terribly unclear.  And, while it doesn’t mention -L, it should be noted somewhere that the possibility of doing find -L complicates the problem substantially. Commented May 10, 2024 at 21:38

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.