`jira board list` hangs.

[realtime-neil]

Describe the bug jira board list hangs.

Please provide following details

1. JiraCLI Version:

   $ jira version
   (Version="v1.1.1-0.20220902194847-5e31a9ae2803", GitCommit="", CommitDate="", GoVersion="go1.19", Compiler="gc", Platform="linux/amd64")
   

2. Are you using Jira cloud or on-premise jira server? Also mention the version for on-premise installation. cloud
3. What operating system are you using? Also mention version.

   Ubuntu 20.04.
   

4. What terminal are you using? Also mention version.

   $ gnome-terminal --version
   # GNOME Terminal 3.36.2 using VTE 0.60.3 +BIDI +GNUTLS +ICU +SYSTEMD    
   

To Reproduce

Steps to reproduce the behavior:

$ unset PAGER && TERM=dumb LC_ALL=C jira board list
-  (press RETURN)

The command hangs, awaiting interactive prompt.

Expected behavior The command should execute, printing the board list, and then exit.

Screenshots N/A.

Additional context N/A.

[realtime-neil]

Here's some weirdness.

When denied a tty, jira board list does execute to completion:

$ TERM=dumb LC_ALL=C time -v nohup jira board list
nohup: ignoring input and appending output to 'nohup.out'
	Command being timed: "nohup jira board list"
	User time (seconds): 0.06
	System time (seconds): 0.03
	Percent of CPU this job got: 15%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.63
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 25144
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 0
	Minor (reclaiming a frame) page faults: 3414
	Voluntary context switches: 398
	Involuntary context switches: 1
	Swaps: 0
	File system inputs: 0
	File system outputs: 8
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0

[ankitpokhrel]

I guess its because of how less behaves in dumb terminal. You can do:

TERM=dumb PAGER="less -d" jira board list

// or

TERM=dumb PAGER=cat jira board list

[realtime-neil]

@ankitpokhrel why use PAGER at all? A dumb terminal should preclude any/all pagers in general --- and certainly less in particular.

[ankitpokhrel]

hmm...its a TUI app so not primarily designed for dumb terminal. I will introduce a new env JIRA_PAGER so one can override pager just for jira-cli if required.

[realtime-neil]

@ankitpokhrel If you'll permit me to say so, I think jira-cli has an identity crisis.

The prominent mention of "cli" in the name of the project implies that the program should be used as a Jira client with a command-line interface. Just now, you declare "its [sic] a TUI app".

The problem is that the latter is a proper superset of the former.

I'm interested in using programs that assume standard UNIX-like calling conventions. That is, they

• read stdin
• write stdout
• can function (and usually function) without a terminal
• can function (and usually function) without interactive prompting

In the more than 18 months I've been following your progress, I'm less and less convinced that jira-cli is such a tool --- and that's okay. I think you should make the hard decisions about supported environments and functionality. But, I think you need more clarity in this regard.

I note that there has been little, if any movement on these issues I've filed:

• https://github.com/ankitpokhrel/jira-cli/issues/187
• https://github.com/ankitpokhrel/jira-cli/issues/213
• https://github.com/ankitpokhrel/jira-cli/issues/291

Taken together, these tickets indicate an inherent lack of support for non-interactive, non-terminal, and/or dumb terminals --- and that's okay. But people like me, who come to your project with these expectations, need to be disabused of such expectations.

I look forward to your reply.

[ankitpokhrel]

@realtime-neil Thank you for bringing this up, and I am sorry that your expectations with the project are not met.

The prominent mention of "cli" in the name of the project implies that the program should be used as a Jira client with a command-line interface. Just now, you declare "its [sic] a TUI app".

Maybe it was my bad to call it a "CLI" but the description always said it's an "interactive" command line tool. I didn't realize that might be the source of confusion. I will try to make this clear on the docs moving forward.

To answer your questions: the project started as a TUI app for my specific use case and will primarily be a TUI app. But that doesn't mean I will agree on and add all of the fancy TUI-related features while ignoring all other requests.

I note that there has been little, if any movement on these issues I've filed:

I am sorry that you feel like your requests are ignored or not addressed on time. There isn't any precise rule on how I prioritize requests or have any specific timeline to complete the requests. Consider that I am the only maintainer of the project right now, and I do this in my free time to solve my own use case. The idea is not to get overwhelmed and abandon the project entirely. Not everything but a lot of the things will be addressed (slowly).

Since this is a fully open-source project, there is always an option to fork and make changes according to your use case without relying on the project collaborators. Or, if you could send a fix, I would be happy to review it and get it merged.

I am thankful for your time and contributions towards making the tool better and hope we could work together to resolve the reported issues and make it suitable for your use case.

[realtime-neil]

Maybe it was my bad to call it a "CLI" but the description always said it's an "interactive" command line tool. I didn't realize that might be the source of confusion. I will try to make this clear on the docs moving forward.

That would be much appreciated, thank you.

I am sorry that you feel like your requests are ignored or not addressed on time.

My feelings are irrelevant. Only the software is relevant. There exist issues against jira-cli that complain about missing/broken functionality in relatively limited environments. These issues have remained open for various reasons. That I am the one who opened them is meaningless. Only your reasons for de-prioritizing them are meaningful.

If you say that jira-cli is a Terminal User Interface application first and a Command Line Interface tool second, then I propose that is one of your reasons.

I ... hope we could work together to resolve the reported issues

That is my hope as well.