LazyCLI throwing "out of range" error after executing bash script
dvjones89 opened this issue Β· 13 comments
Hi Jesse,
Firstly, as someone who uses lazygit and 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!
Dave J
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 lazycli/config.yml
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 registered_command and 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!
Dave J
Hi @jesseduffield π
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,
Dave J
@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
@dvjones89 I've done some digging and the issue comes down to some lines being shorter than others meaning we go looking for columns that aren't there for that line. I've put up a PR for this now :) #10
Hi @jesse @ed-bassett π Thanks so much for looking into this, I really appreciate it π
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.
Thanks again, @jesseduffield and @ed-bassett, you've made my daily life a little easier.
Happy to be of service @dvjones89 ! I'll cut a release shortly and then close the ticket
Lemme know if that new release works for you @dvjones89
Hi @jesseduffield π I can confirm that version 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 :)
Thanks @jesseduffield , I can confirm that 0.1.15 now installs via cargo install lazycli and your fix for the "out of range" exception is working perfectly.
Great job and thanks again! π