Tiny Core Base > TCB Talk

would /usr merge be advantageous for TCL in any way?

<< < (2/4) > >>

gadget42:
i would like to see all the previously written documentation/textbooks/tutorials/etc stay as accurate and relevant as possible for as long as possible
(and in my honest humble dinasour opinion the systemd/windowsification crowd believes it cannot sever these links fast enough to suit whatever change-agents they serve)

patrikg:
I like this idea a lot, you can then remove some search path's, in the PATH.

To throw some wood on the fire, so how do we approach the /opt directory.
Maybe we should also talk a little about it too.

polikuo:
This idea is new to me and I like it.
I write awk script a lot, it annoys me that the paths across distros are not consistent.
Just a quick example to show you all.

Normally, you'd think finding the path with env would be simple enough

--- Code: ---#/usr/bin/env awk
--- End code ---

However, the proper way to invoke an awk script is actually (note the '-f' flag)

--- Code: ---#/usr/bin/awk -f
--- End code ---

If you think appending that flag to the first method would do, you're wrong.
(This won't work)

--- Code: ---#/usr/bin/env awk -f
--- End code ---

The shebang of a linux script is always treated as literal.
Which means, the system will look for an executable called 'awk -f'
Obviously, it won't find anything, the script won't run.

I believe this is the scenario what they are trying to fix.
By putting everything in the same place so nobody has to fix file path again and again.
Come to think of it, it annoys me whenever the downloaded python modules are yelling for file path.
Perhaps they are after this one.

GNUser:

--- Quote from: polikuo on February 29, 2024, 04:03:11 AM ---(This won't work)

--- Code: ---#/usr/bin/env awk -f
--- End code ---

--- End quote ---
Hi polikuo. I've run into that problem before and it's a pain in the neck.

Dealing with the problem of /usr/bin/foo vs. /bin/foo in hardcoded paths is annoying because the purpose of the distinction is unclear at best. So the main selling point for me is that by merging and providing symlinks at filesystem root for compatibility, we eliminate needless complexity and never have to deal with a broken hardcoded path because of this distinction again because either path works!

Dealing with broken hardcoded paths because of applications that are unaware of the TCL convention of using local for extension-derived executables and libraries is a different story. Here the distinction serves a clear purpose for us.


--- Quote from: curaga on February 29, 2024, 02:52:49 AM ---My opinion is that it doesn't matter either way for TC. No advantages and no downsides, and as you found, symlinking just works.

--- End quote ---
Hi curaga. Thank you for sharing your thoughts on this. If it's "no advantages and no downsides" from a technical perspective but a small cosmetic advantage (leaner root filesystem) and a small practical advantage for users (fewer broken hardcoded paths), would you consider /usr merge for TCL16?

curaga:
Yes, fine for TC16.

Navigation

[0] Message Index

[#] Next page

[*] Previous page