Main part
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?
Keywords:
native
builtins
string manipulation
parameter expansion
Background
Just recently I've tapped into the notion, that bash by itself can do a lot of stuff, for which I've used to use the whole bunch of more or less small, special tools like cut, tr, sed, basename, dirname, and so on.
For example setting a variable, but while referring not just treat it as is,
but manipulating what is stored, like, ${var##*/}.
Cryptic? Strange? Yeah, that's what I also thought about it, but my desire for efficiency prevented me from putting it aside. Let me break it down:
${var…}: Refer to what is stored in the variable var.
##: Delete from the beginning on the biggest possible match of a certain pattern…
*/: pattern "any character until including slash"
If the value stored in $var was a path, you've effectively done the same,
as if you've applied the tool basename, stripping of the entire dir name -
the chain of directories until the parent directory of a file - just leaving
the filename, for example, myhomework.org. Well, but more efficient,
introducing, generating less characters, less tool dependence.
One could argue, "Well, but who understands that cryptic stuff? What you save in tool characters, you need more in code explanation", but code comments don't increase processing time ;).
On a more general note, I'm baffled, fascinated:
It dawns to me:
We are in a spectrum.
The 2 poles:
• The common one - unix philosophy - maximization of modularization, use a bunch of tools, each doing just 1 thing but that really good - piping is key
• The minimalist: basics exhaustion - try to get the most out of the single tool, and prefer just using the basics, and less tools, don't act so superficial and wasteful and jump right to yet another tool B, if you are using tool A, and want to do something slightly deviating from it's most common, basic use case, ask yourself, "can tool A also do that, or have I with my new requirement really reached the end of what's possible with tool A ?"
Of course, regarding this spectrum, the boundaries are floating - like dim light.
I feel like this is an essential coding question. Both approaches are in general a good idea, worth to be adopted and a deep-dive. I think both have their pros and cons. And the most exciting question really is:
When it's better to lean to the unix philosophy side, and when to the basics exhaustion?
It's a question of efficiency and simplicity - probably both, but if you ask me especially the latter essential for software freedom, transparency and security.
I fear, the answer is… yeah, exactly: "It depends."
And I'm eager to learn that optimal path of "it depends."
What also appeals to me is the copyleft dimension, this question has:
If with every code snippet you generate you want to promote copyleft as strong as possible, valuing software freedom
higher than cross-platform-capability, in fact, liking the notion of ditching,
ignoring certain platforms, which profoundly simply aren't really building up a world of software freedom, or not so strong like others, or maybe even doing the opposite,
it becomes a very interesting question, what tools you are using and how exclusively. Every tool has a license. Some tools have licenses closer to that vision of a "strong copyleft world", others don't. And with that in sight, maybe you want to just use GNU bash, or GNU emacs, or you like realpath because it's a bash thing, not POSIX, or the builtin new test [[, instead of the cross-platform-friendly old test [, or declaring variables a certain way, breaking compatibility with certain tools inheriting stuff you perceive as being not constructive to building up a software freedom, strong copyleft world.
Same with programing languages: Some programing languages are free, others have trademark.
So, you see: Code, coding style - it seems to trivial, we do it in our daily lives without thinking much about it, but it has profound ramifications in the digital world - just as the daily decision what we put on our plates - is a matter of life and death, for animals - https://yewtu.be/watch?v=U5hGQDLprA8 - our health - nutritionfacts.org - and the environment - https://yewtu.be/watch?v=ZlTBC91L-x0 .
So, its of paramount importance to think about it thoroughly, if the direction we are heading with the things we do right now really is leading us to where we want to be and really is in line with our values, and based on that to make a conscious decision on the things we do on a daily base - "being the change we want to see".
