Closed svenssonaxel closed 4 years ago
I see your problem, but I think another solution would be better.
What if you could override the default name of the ok-file, something like this:
. /path/to/ok.sh ok_name .ok-bash
this will then set an environment variable _OK_FILE
to .ok-bash
. The ok-alias' argument --file
would still override this when used.
Another solution would be not to have .ok
files for bash and ps in the same folder. But then again, .js
and .css
files should be able to be in the same folder, so why not .ok
files...
@secretGeek Your thoughts?
I agree that complicating the parsing as I originally proposed might not be the best.
Another option:
ok-bash
by default try .ok-bash
and .ok
in succession.ok-ps
by default try .ok-ps
and .ok
in succession.I agree that complicating the parsing as I originally proposed might not be the best.
Another option:
- Let
ok-bash
by default try.ok-bash
and.ok
in succession.- Let
ok-ps
by default try.ok-ps
and.ok
in succession.
I think this is a good idea.
I think we should not try .ok-bash
but try .ok-sh
instead.
That’s the spec then, agreed.
IIUC, ok-bash and ok-ps use the same .ok file name and there doesn't seem to be an easy way to dispatch depending on whehter ok-bash or ok-ps is in use.
Some cross-platform projects folders have different scripts and instructions depending on e.g. whether bash is available. Note that this isn't about platform/OS, but on whether bash or ps is available, since that's what will execute the commands listed in .ok.
Suggestion: Extend the syntax of the .ok file so that lines beginning with a
/!([a-z])+ /
prefix are recognized as being limited to that implementation of ok, e.g. bash or ps. Example:ok-bash would then show this menu: