threads / bug / 61615

[Wishlist Bug] git-shell: Support libreadline

Subject: [Wishlist Bug] git-shell: Support libreadline

## tl;dr

3 messages between Jun 10, 2024 and Jun 12, 2024.

replies: 2people: 2as markdown or json

Marc-Jano Knopp· Jun 10, 2024, 13:42 UTC · lore
Hi all!
I would like git-shell to support libreadline:
  https://tiswww.cwru.edu/php/chet/readline/rltop.html

------------------- snip --------------------- Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
  Live in peace.
What did you expect to happen? (Expected behavior)
  git-shell letting me edit the input (Emacs/vi/cursor-keys) and
  access the command history.
What happened instead? (Actual behavior)
  git-shell gave me Thompson shell vibes and sent me into foul-mouthed
  screaming tantrums.
What's different between what you expected and what actually happened?
  Expected libreadline support, got sent to labor camp instead.
Anything else you want to add:
  I installed git-shell as the shell for git users on a git server,
  and filled /usr/local/share/git-shell-commands with various shell
  scripts for git repository maintenance on that server. Having
  git-shell support libreadline would much alleviate two common
  scenarios:
  - commands can be very quickly edited / fixed
  - commands that have been executed before can be quickly accessed
    and either re-executed or edited and executed, especially with
    keybindings like
    ,----[ ~/.inputrc ]---
    | "\C-p": history-search-backward
    | "\C-n": history-search-forward
    `----
    where you start typing "foo", then use C-p/n to go thru all commands
    in history that start with "foo". Life saver.
  Please either simply don't limit the command history (via
  "stifle_history()"), or give users the possibility to define a maximum
  of history lines.
  Location of the history probably does not have to be configurable,
  ~/.git-shell-history will do just fine (for me).
  Thanks for considering this wish-list bug. :-}

Please review the rest of the bug report below. You can delete any lines you don't wish to share.

[System Info] git version: git version 2.39.2 {wanted to try 2.45.1 before reporting, but got shoved into dependency hell} cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Linux 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03) x86_64 compiler info: gnuc: 12.2 libc info: glibc: 2.36 $SHELL (typically, interactive shell): /usr/bin/zsh

[Enabled Hooks] not run from a git repository - no hooks to show ------------------- snip ---------------------

MJK (not subscribed, Cc: welcome)
brian m. carlson· Jun 10, 2024, 21:52 UTC · re: Marc-Jano Knopp · lore

Re: [Wishlist Bug] git-shell: Support libreadline

On 2024-06-10 at 13:42:42, Marc-Jano Knopp wrote:
Show 6 quoted lines
> Hi all!
> 
> 
> I would like git-shell to support libreadline:
> 
>   https://tiswww.cwru.edu/php/chet/readline/rltop.html

Unfortunately, I don't think we can do that. libreadline is GPLv3+, and Git is GPLv2, so it would violate the license to distribute a binary linked that way.

It's possible that libeditline could be used instead to provide similar features, though. If it's important to you that this be implemented, you can send a patch, or you can see if someone else is interested enough to do so.

-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA
Marc-Jano Knopp· Jun 12, 2024, 15:19 UTC · re: brian m. carlson · lore

Re: [Wishlist Bug] git-shell: Support libreadline

On Mon, 2024-06-10, at 23:52:14 (+0200), brian m. carlson wrote:
Show 11 quoted lines
> On 2024-06-10 at 13:42:42, Marc-Jano Knopp wrote:
> > Hi all!
> > 
> > 
> > I would like git-shell to support libreadline:
> > 
> >   https://tiswww.cwru.edu/php/chet/readline/rltop.html
> 
> Unfortunately, I don't think we can do that.  libreadline is GPLv3+, and
> Git is GPLv2, so it would violate the license to distribute a binary
> linked that way.
Oh, it's a legal issue ... *sigh*
> It's possible that libeditline could be used instead to provide similar
> features, though.  If it's important to you that this be implemented,
> you can send a patch, or you can see if someone else is interested
> enough to do so.
Thanks for the hint!
MJK

← back to recent threads