secretGeek / ok-bash

.ok folder profiles for bash
MIT License
89 stars 6 forks source link

Combined parent paths #39

Open doekman opened 1 year ago

doekman commented 1 year ago

Idea from this PR:

I like the concept and have often wondered if something like this would be worth doing.

What have you found from using this feature? Has it been particularly helpful? Do you use it a lot?

I sort of assume you do, or you wouldn't have submitted the PR.


Some discussion / conversations I've had about this inside my head:

I've always been tempted to add something like this, because "searching up" is usually a very cheap search (since there's only one direct path upwards...)

I'm a little worried if it could present a security risk, or just an "unexpected behaviour" risk. But I can't think of any major worries here -- other than the need to consider relative paths -- is the command executed from the current path of the caller, or the current path of the ".ok" file??


In my mind, when thinking about this feature, it always involved combining the .ok files.

So if there are 3 .ok files, like this ----

/.ok             .... containing just       'echo "hello from the root folder...."'
/foo/.ok         .... containing just       'echo "hello from foo"'
/foo/bar/.ok     ...  containing just       'echo "hello from foo/bar"'

then running "ok" from the /foo/bar/ folder ....

/foo/bar/$ ok

...might output some combination (a UNION) of the possible commands... like:

1:  echo "hello from foo/bar"
2:  echo "hello from foo"  
3:  echo "hello from the root folder...."   

And/or -- if the union of commands are to be shown, there might need to be some indication of whether the command is from the current folder, or a higher folder (and which one). For example "dots" (..) could be used as indication of commands that have been brought in from higher up .... e.g. -- in our case above where commands are provided from three different .ok files...

1:  echo "hello from foo/bar"
2..:  echo "hello from foo"  
3...:  echo "hello from the root folder...."   
  • Line 1 -- Shows No dots between the "1" and the ":", which means it's from the current folder (same as ok currently uses)
  • Line 2 -- Show Two dots between the "2" and the ":", which means it's from one folder up
  • Line 3 -- Shows three dots between the "3" and the ":", which means it's from one folder up

...And further if there are named commands -- then only the most "specific", most "local" .ok file would apply. (Sort of like the specificity rules in CSS.

So if you had three .ok files available from your current location, and they all had a named command with the same name, e.g. "deploy" -- like this:

/.ok             .... containing just       'deploy: echo "deploying everything..."'
/foo/.ok         .... containing just       'deploy: echo "deploying /foo and its children"'
/foo/bar/.ok     ...  containing just       'deploy: echo "deploying /foo/bar and it's children"'

...in that case running "ok" from the /foo/bar/ folder would combine the union of all commands -- showing the most specific first.... and where there are named commands, only the most specific version of the command is available..... SO in this case

/foo/bar/$ ok

..would only output this one possible command:

deploy: echo "deploying /foo/bar and it's children


Now -- all of that aside -- I'm glad you're NOT trying to combine / union / "cascade" the .ok files like that at all .... i always got caught up on that issue, and i think it's quite a doozy.

I wouldn't mind leaving open the possibility of combining/cascading the .ok files, at some later point. And I think you've left that possibility open.

So all up -- i like the concept -- and if you've used it for a while and found it a welcome addition to your life, then I support the idea.

(One more thing i want to write down -- for completeness)

The other thing that I thought the feature might eventually entail -- if/when combining files was implemented -- is that a ".ok" file in your home folder, or perhaps in a special well-known location like "~/ok/.ok"

...might be "always" on the search path, if you understand what I mean.

SO -- if there is no .ok in the local folder, or in the parent folder... or all the way up to the root folder... then one final check is done to see if the special well-known-path of "~/ok/.ok" exists -- and if so, then that is shown/used.

I'm not requesting that any of these concepts are added to the current PR. I'm just making sure you know the kind of things I've thought of with this, in case I am hit by a bus tomorrow. You never know!!

cheers lb