toumorokoshi / tome Goto Github PK

As specified in the design, add the exec, help, commands, and tome commands to a tome instance.

• completion should include these options.

add a new command "help" that is available in any tome environment.

This will be a backwards-compatible change: it'll overwrite the any proprietary "help" commands.

Tome will no longer attempt to infer the shell from the SHELL environment variable.

All references should be cleaned up:

• src/ lib_tests.rs 113: env::set_var("SHELL", "bash")
• src/ script.rs 107: true => Command::new(var("SHELL").unwrap_or_default()),
• src/commands/ init.rs 168: let shell_env = match env::var("SHELL") {

This seems to happen even though bash is a valid shell. Happens on version 0.7.3

rather than just allow completion on any script, scripts should include a flag in their documentation at the top. something along the lines of:

# tome-completion

this will tell tome to try completion if it sees it. Tome trying to execute completion also runs the script, which can have potentially destructive affects, so it should be opt-in.

e.g. see this error that results in an exec failure when attempting to complete:

$ app what connector
8)          called      completion  echo        error       Exec        failed:     format      (os

See https://github.com/toumorokoshi/tome/pull/5/files#r606878773 for context.

We may want to support other common prefixes that are used in scripting languages. Currently tome only supports hashtags, which covers bash, python, ruby, and perl.

Environment:

# ... using latest tome macos binary

$ /usr/bin/env bash --version
GNU bash, version 5.0.11(1)-release (x86_64-apple-darwin18.6.0)

$ echo $SHELL && echo $BASH
/bin/bash
/bin/bash

# ... (also tried on Kali Linux, latest w/tome linux binary)

Bash Init:

eval "`~/.local/bin/tome init clinja /scripts $0`"

Scripts:

/scripts
$ tree
.
└── create-app
    ├── api
    └── console

1 directory, 2 files

# directory: `create-app`
# files: `api`, `console`

File Content:

api:

 $ cat create-app/api
#!/usr/bin/env bash
echo "creating api app!"

console:

 $ cat create-app/console
#!/usr/bin/env bash
echo "creating console app!"

Expected:

# fluid autocompletion
clinja create-app api
creating api app!

Actual:

 $  clinja
This is an instance of tome, running against the directory /scripts.
The commands are namespaced by the directory structure.
Full list of commands available are:
 create-app api:
 create-app console:

# `create-app` _does_ autocomplete (expected)
# however, `create-app` repeats whenever tab is invoked (unexpected)
$  clinja create-app create-app create-app

# `api` must be _manually_ entered, instead of relying on autocomplete (expected), which renders the expected output
$  clinja create-app api
creating api app!

User Error?

One feature from sub I don't see here is that sub provides to scripts an environment variable containing the "root" directory of the project.

It's documented here in the README:
https://github.com/qrush/sub/blob/4bcb94f0c14f911fc77ac642318c5d19b359c5cd/README.md?plain=1#L58

So, if a project is named rush, an environment variable named _RUSH_ROOT would be set.

Since compatibility with sub seems to be a goal, it would be nice to support this, or document the recommended refactoring for people converting scripts.

👋 (this is spawned issue from #2, which has become a bigger discussion)

Long time sub fan and found your project thanks to a friend. Thanks for setting up a new incarnation! I've setup a sub based cli at the last couple places I've worked and it's been great. Interested to play with tome and see if it's my new goto.

When trying to run the current HEAD of tome, I get a test failure:

bash-5.1$ cargo test
    Finished test [unoptimized + debuginfo] target(s) in 0.01s
     Running target/debug/deps/tome-2fa1d8bb501aff4b

running 16 tests
test commands::tests::test_should_not_source ... ok
test commands::tests::test_usage ... ok
test commands::tests::test_should_source ... ok
test commands::tests::test_help ... ok
test tests::test_dangerous_characters_quoted ... ok
test tests::test_script_directory_argument ... ok
test tests::test_directory_completion ... ok
test tests::test_script_in_directory ... ok
test tests::test_script_in_directory_not_found ... ok
test tests::test_root_directory_completion ... ok
test tests::test_simple_script ... ok
test tests::test_source ... ok
test tests::test_use_arg ... ok
test tests::test_help_page ... ok
test tests::test_simple_script_completion ... ok
test tests::test_source_completion ... FAILED

failures:

---- tests::test_source_completion stdout ----
thread 'tests::test_source_completion' panicked at 'assertion failed: `(left == right)`
  left: `Ok("")`,
 right: `Ok("foo baz\n")`', src/tests.rs:43:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    tests::test_source_completion

test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.17s

I investigated this by setting up a script to recompile tome and prepend the compiled ./target/debug/tome` to my path (otherwise system tome would be used) and (edited due to my misunderstanding test harness) re-run the tests across the various git tags. In my testing this one test has failed from v0.1 onwards to v0.7.1.

A couple questions:

• Are you seeing different test results than I am?
• Is the desired behavior still that source style scripts allow for completion?
• If I'm hacking on this, would you appreciate things like Github Actions for CI and patches for that test failure?

I'm switching from sub to tome to take advantage of the nesting (e.g. my-command nested nested cmd) but it seems that scripts doesn't receive the arguments passed when calling the tome instance.

I have this setup:

.zshrc

eval "$(tome init my-tome ~/my-scripts zsh)"

~/my-scripts/python-test

#!/usr/bin/env python
import sys

print(sys.argv)

When I run the script through tome I get:

▶ my-tome python-test 1 2 3 4
['/home/hwbb/my-scripts/python-test']

Instead of:

▶ my-tome python-test 1 2 3 4
['/home/hwbb/my-scripts/python-test', '1', '2', '3', '4']

we should introduce and e2e test script which can be added to CI to verify behavior with supported shells (bash, zsh, fish) and OS (OSX, linux).

System/Version
debian:12, zsh: 5.9, tome v0.9.0
macOS 12.6, zsh: 5.8.1, tome v0.9.0

Example command (modified example/dir_example/bar:

#!/usr/bin/env bash
# COMPLETE

if [[ "${@:-1}" == "--complete" ]]; then
    echo "--bar1 --bar2 --not-bar"
    exit
fi
echo "bar $*"

Behaviour: after typing --<TAB> the tab complete options are displayed correctly however after typing the next character and typing <TAB> a compgen warning is printed. Continuing to type results in additional compgen warnings being printed however, the argument is completed.

# no compgen warning
7aa02469b61d# tool bar --<TAB>
--bar1     --bar2     --not-bar

# compgen warning after <TAB>
7aa02469b61d# tool bar --bcompgen:14: bad option: --
--bar1     --bar2     --noarbar

# Multiple <TAB>s ends up completing the option however prints the compgen warning with each <TAB>
0df544f0a4b9# tool bar --b<TAB>compgen:14: bad option: --
ar<TAB>compgen:14: bad option: --
              tool bar --bar<TAB>compgen:14: bad option: --
1-bar1  --bar2
bar --bar1

We can do that also. People want/expect the ability to compile if desired.

What we could do is setup homebrew to either get most recent release, OR compile from scratch if wanting it built from master.

If you like that approach, I'll break out a follow up task to address.

Originally posted by @zph in #4 (comment)

With the folder layout of:

script1
script2
non-executable-file

Autocomplete shows all of them.

Do we want to filter down to only things set as executable? Non-executables won't work when the exec happens and might be an invalid format like markdown.

Currently these are selected based on presence in folder and excluded if in ignore list, but we could potentially stat each one to find only the ones with +x set.

Yes. Which will require keeping version synchronized in two place.

I could break out a task to make a version_bump helper script that updates the version in both places 🤔 to make sure it reliably happens?

Originally posted by @zph in #4 (comment)

Thanks for the new release. However, it seems that the Cargo file is not getting updated during the release process, and it seems that what Tome is using to report its version. So although i downloaded 0.11.0, running tome or tome --version will report the version as 0.1.0 instead.

Also, the word "echo" is printed out, which appears to a mistake:

Context: https://github.com/toumorokoshi/tome/pull/4/files#r598067349

Yes! I think I did that in the later PR.

Ok w/ leaving it as a nit that we address later in a docs cleanup task? If so, I'll add a placeholder issue to make a pass at documentation cleanup when most interface changes have landed.

Originally posted by @zph in #4 (comment)

There is a bug in tome v0.7.0 where an argument that includes quoted shell-style expansions will be expanded later on, during the eval phase.

This is because tome receives the arguments as an expanded array, preserving quotes:

# final function is
s <script_dir> $@

But the output is consuming those arguments and re-emitting them, unquoted:

tsutsumi:~
$ s test "()"
bash: syntax error: unexpected end of file

Example:

$ ~/bin/tome ~/.ytlaces/cookbook/ test "()"
/home/tsutsumi/.ytlaces/cookbook/test ()%

As the shell would have handled any expansions as the arguments were fed into tome in the first place, there's no need to emit them in an unquoted form, which would make them subject to subsequent shell evaluation.

Using zsh on OSX

I have a folder in the root level of my structure. Running my script with that folder name correctly says that it's a folder. When I try and tab complete it only prints out the root level commands instead of the item in that folder.

OIddly, this doesn't work for one of my commands but does work for another. Both are declared in my startup scripts the same way.

Working command to

Broken command app

TODO: works but needs repo configuration in Github.

Originally posted by @zph in #4 (comment)

This is the error I get with 0.7.4. It works fine if I revert to 0.7.1

macbook-pro $ ~/bin/tome-osx init bb ~/repos/scripts/bb $0 
echo Unknown shell -zsh. Unable to init.%

I'm a long-time sub user and run the resulting scripts on servers as well as my laptop. In a server context, I think running an init function against the shell first could be awkward or error prone.

I would like a convenient way to run scripts in a server context without init. It can be done now, but the syntax is awkward:

eval (tome command-execute path/to/scripts/ -s fish -- my-command)

It looks like the reason that eval is used here is to allow completion to work, which isn't necessary for server/scripting use. Also, maybe passing the shell is not required either if completion doesn't need to be supported. So something like this could made to work:

tome run  path/to/scripts/ -- my-command

But that's still a bit unintuitive if you are used to calling the command by it's custom name and not as tome.

So another alternative is to supply an option to print out script which would not support completion, but would simply one line of bash:

my-command tome script>~/project/bin/my-command

Now ~/project/bin/my-command can be checked into Git and would work just like the function, but without the completion support. From here, ~/project/bin/my-command can be used on deployments without further initialization.

But maybe I'm missing the obvious and on the server the scripts could just be called directly, without using tome at all--- that would actually be nice to not have one more dependency on package which requires manual installation. This would be OK as long as the scripts don't call each user using the custom command name. In this case, I guess what would be really beneficial is a simple shell-script version of the tool that doesn't support completion just handles executing the scripts.

As tome is moving to 1.0, one particular design that could be improved is tab completion. Consider this a request for comments or design.

Today, tome provides some primitive support for tab completion, by running the script with the --complete argument and expecting a list of strings with the possible candidates when a user attempts to tab-complete on a terminal command.

This works fine, but doesn't allow for more complex completion semantics such as those offered by zsh.

From a design standpoint, it would be great to just enable support for various shell's completion without offering first-class functionality for any specific one.

I haven't read too deeply on this topic myself, so I'm curious if there's suggestions from others who use tome.

👋

Long time sub fan and found your project thanks to a friend. Thanks for setting up a new incarnation! I've setup a sub based cli at the last couple places I've worked and it's been great. Interested to play with tome and see if it's my new goto.

When trying to run the current HEAD of tome, I get a test failure:

bash-5.1$ cargo test
    Finished test [unoptimized + debuginfo] target(s) in 0.01s
     Running target/debug/deps/tome-2fa1d8bb501aff4b

running 16 tests
test commands::tests::test_should_not_source ... ok
test commands::tests::test_usage ... ok
test commands::tests::test_should_source ... ok
test commands::tests::test_help ... ok
test tests::test_dangerous_characters_quoted ... ok
test tests::test_script_directory_argument ... ok
test tests::test_directory_completion ... ok
test tests::test_script_in_directory ... ok
test tests::test_script_in_directory_not_found ... ok
test tests::test_root_directory_completion ... ok
test tests::test_simple_script ... ok
test tests::test_source ... ok
test tests::test_use_arg ... ok
test tests::test_help_page ... ok
test tests::test_simple_script_completion ... ok
test tests::test_source_completion ... FAILED

failures:

---- tests::test_source_completion stdout ----
thread 'tests::test_source_completion' panicked at 'assertion failed: `(left == right)`
  left: `Ok("")`,
 right: `Ok("foo baz\n")`', src/tests.rs:43:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    tests::test_source_completion

test result: FAILED. 15 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.17s

I investigated this by setting up a script to recompile tome and prepend the compiled ./target/debug/tome` to my path (otherwise system tome would be used) and (edited due to my misunderstanding test harness) re-run the tests across the various git tags. In my testing this one test has failed from v0.1 onwards to v0.7.1.

A couple questions:

• Are you seeing different test results than I am?
• Is the desired behavior still that source style scripts allow for completion?
• If I'm hacking on this, would you appreciate things like Github Actions for CI and patches for that test failure?

ah ok, I see what you did. It sounds like you're planning on switching to always passing in a shell argument which is good. If you want to merge this in and address that in a future PR, that's fine too.

Originally posted by @toumorokoshi in #4 (comment)