relativity of paths:

the fact that "paths relative to where the user is launching the program from" EVEN FUCKIN EXIST is such a fuckin idiotic thing.

it means that there's ONLY SINGLE ONE SPECIFIC (unknown to the user) PLACE FROM WHICH TRYING TO RUN A PROGRAM WON'T FAIL.

which is the most moronic thing ever.
and, as usual, linux bullshit turd smell. nobody except linux geniuses could have ever come up with such galactic size bullshit.

Unless I’m misreading, that also existed in dos.

What's wrong with path relativity? It existed everywhere and used to manipulate files from directories other than the exe is in. I don't see how could you generalize that programs are meant to be run from only one directory...

@Root
doesn't matter, the point is that it's the bullshittest bullshit idea that ever bullshitted.

not every rant of mine is an explicit case trying to explain why linux is the worst thing that ever happened to computing, some rants are just about some bullshit that (surprisingly, occasionally) is not linux's fault.

but yeah i made an assumption about where the moronism comes from, our of experience about where it usually comes from. that assumption was incorrect in this specific case.

doesn't change a thing about any of the two points (giving programs paths relative to current user's directory, and linux being shit and cause of all our today's shit, both separately) either.

@HitWRight
there's nothing wrong with relative paths
there's everything wrong with OS providing some paths to the program by default as relative to the user location, and some others as relative to the exe location.

everything wrong with the fact that if i run the same program with the same parameters from two different "ls" places, one time it works, another one it breaks.

@HitWRight
"I don't see how could you generalize that programs are meant to be run from only one directory..."

programs are meant to be run from ANYWHERE, WHICH IS PRECISELY WHY HAVING ANY PATHS (except of an explicit $os->currentUserDirectory path) SET, SENT, RECIEVED, AS USER'S WORKING DIRECTORY IS THE UTTERLY MOSTLOBOTOMIC SHIT THAT IT IS.

@HitWRight
or would you like me to modify all SQL servers so that any column identifier without explicitly stated table name will infer and try to use the last explicitly stated table name within all the commands that have been ran on the machine up to that point?

the point is clear separation:
app.path() -> wherever the exe that's running is
os.user.currentPath() -> wherever the user is in his dir/ls/cd chain

i have no idea why the default paths that the program gets from OS when it starts would need to be relative to userspace.

i'm not a user, i'm a fuckin program! i have no idea if and why user went 10k levels deep into some folder structure and i don't care!

admittedly this might not be an outright OS issue, just the issue of the codebase i'm working with, but even the fact that it's an issue in such a non-shit codebase points to some os-level issues.

the fact itself that paths are such an issue so much of the time points to there being something wrong
\ vs /, quotes or no quotes, FUCKIN IS A FUCKIN PATH TO A FILE WHAT'S SO FUCKIN HARD ABOUT MAKING IT WORK IN A SENSIBLE WAY.

If my script is path relative then I can have it in one place, while the data it operates on resides elsewhere. So if running against multiple locations with data then I only need the script to be defined once.

@AtuM
"I hope you get better soon, sir."

probably not since the web laxative keeps existing and keeps forcing me to interact with it.

Well there's only one alternative to relative paths, and That's absolute paths...

So you're saying, that if I send someone a software, It's bullshit if it reads from ./data/data1.bin

But it's perfectly ok if it reads from
/home/hazarth/projects/mySoftware/data/data1.bin

Despite the end user not having such folder structure...

Sorry, what? Or would you rather the users kept manually setting paths to everything on first launch?

If anything relative paths are *the* solution to software-system transiency and I have no Idea why you would attribute this to linux specifically since this was the case in DOS too, how do you think "Dir" worked? It completely depends on where you run it from... The CWD (current working directory) was a thing since ever systems needed filestructures....

@Demolishun
bullshit.

if your script is user-path-relative, then it will fail the user runs it from the wrong path.

i thought there's smart people here.

what's hard to understand about the simple universal fact that if:
programName filename:ext runs correctly

then
programName filename.ext should also run correctly.

even if my current working directory is different.

the same command should result in the same result, i'm not much of a theory guy, but isn't that some kind of a rule, at least in functional programming, that the exact fucking same function call with the exact same fucking same parameters should result in the exact same fucking execution of a function?

ESPECIALLY when we're talking the level of searate PROGRAMS, as opposed to functions, which is the only differentiation between programs and functions, that the programs should have this kind of isolation?

@Midnight-shcode I mean yeah, it's more complex. And now developers are forced to thread lightly, when different environments are introduced, but it introduces a lot of power for organising data on our machines.
And do believe me, that 90+% of people like relative paths resolution more than recompiling the software, just because you want to change where the software spits out it's results.
I'm sorry you got bitten by the feature all OSes have.

@HitWRight
and i can tell you the whole thing would be at least 90% better if there was a clear separation.
but no, os gives you 20thousand different path values all of them scoped differently and nearly no info anywhere about how.

i get your point and i agree.
at the same time, satisfying that point needs a single variable (path relative to my exe). and then absotule paths.

oh, and also the path user is currently in.

the three types are fine and good.
it's the mixing of them that causes and is caused by lobotomy.

What are you even talking about?

The purpose of a relative path is that you as the user get to specify a workspace for the program. Dependencies, configuration, other executables, and everything else that isn't definitely nonglobal should, by default, be referred to with an absolute path.
Just because relative paths are available doesn't mean you should be using them when they don't make sense.

Also, you should have an envvar to specify
The config directory
The logging method and target
The path to any dependencies, which should fall back to referring to them without path so they're resolved from PATH
Any global state the program might decide to write, so that you can workspace it even though it wasn't meant to be workspaced by default.

ADDITIONALLY
The directory a program was pulled from doesn't necessarily exist, may be ambiguous, may be selected unreliably since distros tend to place package-managed binaries in funny places, is likely a directory with tens of thousands of other entries, etc. It's not something you should care about on Linux.

In Unix-like OSes, every feature has a purpose. If you're not sure how to access something you should read up on the difference because otherwise you're likely to do stupid shit like depend on ./extras.so and then be surprised when it proves unsustainable.

This is also a thing on windows btw, it just switches to the directory of the main executable when launching a shell-integrated app and since you otherwise run your executables from Explorer the running program inherits Explorer's working directory.
In conclusion: what you perceive as the right way is an artifact of how you may have been working on Windows and nobody actually designs OSes like that.

I'm still trying to process what's exactly the problem.........

Cause it sounds to me like sth. very trivial to implement in every language?

E.g. bash, use readlink with BASH_SOURCE.

Python - use e.g. os.path.abspath...

And so on.

And I think that the reason is - without doing any research - that it's hard to utilize absolute pathes. For many reasons.

File path length is still limited in windows to 254 chars If I remember correctly.

Absolute path would mean you cannot execute any program without a fullly resolved path, symlinks wouldn't exist, you'd need to know in advance where a program / script exist.

That sounds pretty insane to me.

Even a simple ./script wouldn't work if I understand your logic correctly, as it would have to be <resolved path>/script.sh.

Hence, every language with a CLI mode has a relative path defining it's origin.

And usually there's always a way to resolve it to an absolute path.

But it must be relative first I guess... Could be wrong, never thought about that, as it is a trivial matter most of the time to resolve it.

@IntrusionCM Then to fuck it all up: symlinks

@IntrusionCM my guess, the guy is drunk AF 🤔