LazyCLI throwing "out of range" error after executing bash script
dvjones89 opened this issue · comments
Firstly, as someone who uses
lazydocker on an hourly basis, I can't thank you enough for the tools you're creating here. I've previously thrown you a few dollars via Donorbox, though I think it's time I topped up that pot of beer money
I'm starting out with your latest tool,
lazycli, and it's already opening new doors for me. I have, however, encountered one issue that I can't quite work through and wondered if you could help.
I currently have a simple
bash script containing a single command (using the
jira cli from https://github.com/go-jira/jira)
cat ~/dev/jira.sh jira list --query "resolution = unresolved and assignee=currentuser() and sprint in openSprints() ORDER BY status asc"
If I run the bash shell directly within the terminal, it outputs my list of assigned Jira tasks, as expected:
~/dev/jira.sh EDG-3889: Some users are overlooked for pole-price messages and price_change_enabled checks since their association with a station is implicit, rather than being explicitly associated with a station in our admin tooling. EDG-2416: Ability to recognise and validate UK and US telephone numbers when setting up new users EDG-3849: Surface the "key" field on brands to the API Gateway EDG-3698: Tax Rates at Contract Level (Any Supplier) EDG-3595: Pole price alert received email only to first station manager
Strangely, if I execute the same script as an argument to
lazycli, I'm seeing a runtime error since due to some kind of range overflow:
RUST_BACKTRACE=1 lazycli -- ~/dev/jira.sh ⡿thread '<unnamed>' panicked at 'range end index 107 out of range for slice of length 101', /Users/dave/.cargo/registry/src/github.com-1ecc6299db9ec823/lazycli-0.1.14/src/parse/mod.rs:38:26 stack backtrace: 0: rust_begin_unwind at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/std/src/panicking.rs:493:5 1: core::panicking::panic_fmt at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/panicking.rs:92:14 2: core::slice::index::slice_end_index_len_fail at /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/slice/index.rs:41:5 3: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once 4: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter 5: lazycli::parse::parse 6: lazycli::event_loop::get_rows_from_command note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. ⣯
If it helps, I've previously had this exact configuration working, though something seems to have changed, possibly something subtle about the output from the
jira.sh script that's suddenly causing
lazycli to error?
Are you able to take a look and help me out with this please, dude?
Thanks in advance for your assistance!
Hi again, Jesse 👋🏼
I wanted to let you know that, miraculously,
lazycli has risen from the dead and is now successfully parsing the output from my
jira.sh bash script:
lazycli -- ~/dev/jira.sh > EDG-3698: Tax Rates at Contract Level (Any Supplier) EDG-2416: Ability to recognise and validate UK and US telephone numbers when setting up new users EDG-3849: Surface the "key" field on brands to the API Gateway EDG-3595: Pole price alert received email only to first station manager EDG-3889: Some users are overlooked for pole-price messages and price_change_enabled checks since their association with a station is implicit, rather than being explicitly associated with a station in our admin tooling. ▲/▼/j/k: navigate, /: filter, esc: clear filter, q: quit, $: open config file (open /Users/dave/Library/Application Support/lazycli/config.yml) No profile selected
As you can see from the above, the
~/dev/jira.sh command isn't matching against any
lazycli profiles, though I do have
~/dev/jira.sh as a
registered_command in my
profiles: - name: jira registered_commands: - ~/dev/jira.sh key_bindings: - key: o command: jira browse $(echo $0 | sed 's/://') - key: g command: open https://github.com/pulls?q=is%3Apr+author%3Advjones89+archived%3Afalse+is%3Aclosed+$(echo $0 | sed 's/://') - key: r command: jira transition --noedit 'Code Review' $(echo $0 | sed 's/://') - key: t command: jira transition --noedit 'Test on staging' $(echo $0 | sed 's/://') - key: p command: jira transition --noedit 'In Progress' $(echo $0 | sed 's/://') - key: d command: jira transition --noedit 'Done' $(echo $0 | sed 's/://')
Afrer some experimentation, I've realised that the
~ component of the path is being evaluated (presumably by my shell) to
/Users/dave/ and, sure enough, using the full script path in the
registered_commands section allows the
jira profile to be loaded successfully.
profiles: - name: jira registered_commands: - /Users/dave/dev/jira.sh
Why am I telling you all of this? Well, until today, I'm pretty confident I was successfully using
~/dev/jira.sh as my
lazycli was successfully loading the
jira profile, though perhaps I'm losing my mind
Either way, if the stack trace I shared above had you wracking your brains, perhaps an extra nugget in this follow-up message gives you a missing clue
Thanks again for all your do!
I'm sorry to say the aforementioned
range end index out of bounds issue has resurfaced, though this time, I've made it trivial to reproduce via the attached jira.txt file
lazycli cat jira.txt thread '<unnamed>' panicked at 'range end index 61 out of range for slice of length 59
I'm already really missing the workflow that
lazycli gave me and, if possible, I'd love to work with you to investigate (and hopefully fix) the cause of the above error
Please let me know if you have chance to look at this and if/how I can help you.
Thanks so much,
@dvjones89 hey there, sorry I've been so slack on keeping up to date with these issues, my work has been flat out lately.
Based on that stack trace it looks like we've got an out-of-bounds exception with the following line of code:
push(&mut cells, chars[last..*position].to_owned());
What would fix this is to obtain a slice of the chars array but handling the out of bounds issue i.e. if we want positions 5 through 10 but the array only goes up to 7 then we'll get 5 through 7. I am not too sure how best to do this in rust though
Awesome to see the fix for this issue merged into
master. I've manually built a binary from the
HEAD commit and can confirm that the issue seems to be fixed (I can run
lazycli cat jira.txt without issue
I'll leave this issue open for now, in case you only consider it closed on the fix is shipped in an official release, though please feel free to close this report whenever suits.
Happy to be of service @dvjones89 ! I'll cut a release shortly and then close the ticket
0.1.15, downloaded as a binary from the releases page, is working beautifully. It looks like Cargo is still serving up
0.1.14, though perhaps the new release just needs time to propagate?
it may be that the github action I've got setup doesn't actually release to cargo. I'll see if I can do a manual publish
Manual publish completed :)