Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Run interactive commands in Gemini CLI

developers.googleblog.com

Post reply on HN
Print view View original

31–40 of 80 posts

Re: Run interactive commands in Gemini CLI

#31

Post by ilikepi »

thallavajhula wrote: post #29

Aside: The demo shows git commands being run in the CLI. I absolutely hate it when devs use a commit message that says "chore: my first commit from gemini cli" - I get that it's meant for the demo, but in general too, I've seen codebases that enforce these commit prefixes such as "chore", "feat", "bugfix" etc. Is there any real value to that? Besides wasting up the 50 character limit on the first line of the commit m…

> I've seen codebases that enforce these commit prefixes such as "chore", "feat", "bugfix" etc. Is there any real value to that?

It's a choice some teams make, presumably because _they_ see value in it (or at least think they will). The team I'm on has particular practices which I'm sure would not work on other teams, and might cause you to look at them with the same incredulity, but they work for us.

For what it's worth, the prefixes you use as examples do arise from a convention with an actual spec:

https://www.conventionalcommits.org/en/v1.0.0/

Re: Run interactive commands in Gemini CLI

#32

Post by snthpy »

I couldn't tell from the post how this will affect Gemini's ability to assist better as a result.

I guess for Google this will be a treasure trove of real developer interactions to train on.

I might try this once Gemini 3 comes out. Until then, if you're running tmux or zellij, this seems like a worse user experience since you're in a subwindow and have less screen real estate to work with.

Re: Run interactive commands in Gemini CLI

#33

Post by jval43 »

ilikepi wrote: post #31
thallavajhula wrote: post #29

Aside: The demo shows git commands being run in the CLI. I absolutely hate it when devs use a commit message that says "chore: my first commit from gemini cli" - I get that it's meant for the demo, but in general too, I've seen codebases that enforce these commit prefixes such as "chore", "feat", "bugfix" etc. Is there any real value to that? Besides wasting up the 50 character limit on the first line of the commit m…

> I've seen codebases that enforce these commit prefixes such as "chore", "feat", "bugfix" etc. Is there any real value to that? It's a choice some teams make, presumably because _they_ see value in it (or at least think they will). The team I'm on has particular practices which I'm sure would not work on other teams, and might cause you to look at them with the same incredulity, but they work for us. For what it's w…

Just because someone put up a fancy website and named it "conventional" doesn't mean it's a convention or that it's a good idea.

The main reason this exists is because Angular was doing it to generate their changelogs from it. Which makes sense, but outside of that context it doesn't feel fully baked.

I usually see junior devs make such commits, but at the same time they leave the actual commit message body completely empty and don't even include a reference to the ticket they're working on.

Re: Run interactive commands in Gemini CLI

#34

Post by KronisLV »

sunaookami wrote: post #15
jasonjmcghee wrote: post #7

I've had a pretty poor experience with Gemini. I've had to convince it to do things it should just be able to do but thinks it can't for some reason. Like reading from a file outside of the project directory- it can do it fine, but refuses to unless you convince it that no it actually can. Also has inserted "\n" instead of newlines on a number of occasions. I'd argue these behaviors are much more important than being…

Gemini doesn't seem to be trained on tool use (which Claude is) so it quiet often thinks it can't do something it certainly can and does a lot of nonsense. For me it fails nearly everytime while it's trying to read project files because it uses relative paths instead of absolute so I've put "For your "ReadFile" and "WriteFile" tool, you MUST use absolute paths to files" in my system instructions. Speaking of system i…

My experience with Gemini 2.5 Pro has oddly been better, maybe because I use RooCode/Cline? It was oddly apologetic, though, wasting tokens on lamenting its failure when it fails to do something and whatnot, instead of just getting on with the solution.

At the same time, even the big versions of Qwen3 Coder (480B) regularly mess up file paths and use the wrong path separators, leading to files like srccomponentsMyComponent.vue from being created instead of src/components/MyComponent.vue.

> And it still puts code comments nearly everywhere, it drives me nuts.

I’ve had the issue of various models sometimes inserting comments like “// removed Foo” when it makes no sense to indicate the absence of something that’s not necessary there for a code block that isn’t there.

At the same time, sometimes the LLMs love to eat my comments when doing changes and leave behind only the code.

How silly (and annoying). It’s good to be able to try out multiple models with the exact same prompts though, maybe I should create my own custom mode for RooCode with all of the important stuff I want baked in.

Re: Run interactive commands in Gemini CLI

#36

Post by dustypotato »

> It's not just a stream of text; it's a live feed.

LLM wrote this article it seems.

For me Gemini CLI is not as good as Claude Code and sometimes writes more code than necessary and makes it hard to maintain. but hope it gets there with gemini 3.0 release. It's open source so I can imagine it getting there faster with community contributions.

Re: Run interactive commands in Gemini CLI

#37

Post by dustypotato »

thallavajhula wrote: post #29

Aside: The demo shows git commands being run in the CLI. I absolutely hate it when devs use a commit message that says "chore: my first commit from gemini cli" - I get that it's meant for the demo, but in general too, I've seen codebases that enforce these commit prefixes such as "chore", "feat", "bugfix" etc. Is there any real value to that? Besides wasting up the 50 character limit on the first line of the commit m…

If you're looking in the commit tree for which commit fixed a certain bug, but didn't fix it fully , for example , you first look at all the `fix:` and then if it matches, you read the rest. You just write `fix: Thumbnail wasn't updating after upload` to `Fix for Thumbnail not updating after upload`, which isn't really wasting characters.

But I'm also not a fan of this being an enforced convention because somebody higher up decided he/she it brings some value and now it's the 101st convention a new dev has to follow which actually reduces productivity.

Re: Run interactive commands in Gemini CLI

#38

Post by dustypotato »

The posted link says: >The new interactive shell is enabled by default in Gemini CLI as of v0.9.0.

but https://geminicli.com/docs/tools/shell/#enabling-interactive... > To enable interactive commands, you need to set the tools.shell.enableInteractiveShell setting to true.

Seems contradictory. I can't get it to work in either case .

Re: Run interactive commands in Gemini CLI

#39

Post by heeen2 »

I made a mcp that would use a pty lib to allow claude to debug a TUI app I was writing with ok-ish results. ultimately I wanted to see what was happening myself so when I need interactive I just tell it to use tmux-cli to capture the neighboring pane. https://github.com/pchalasani/claude-code-tools/blob/main/do... maybe turning that into a mcp with more guardrails and integrated guide to the agent would make it more popwerful

Re: Run interactive commands in Gemini CLI

#40

Post by lazarie »

Trying to use Gemini CLI is one of the most frustrating experiences with any tool I've had in over two decades of working with software.

It's seemingly very hard to understand how it should be configured at all if you don't have a personal Google account. Rather than just using your credentials to login and start, you need to find some forum posts of people that have reversed engineered that you need to use a Google Cloud environment variable, even if you are operating without a "Code Assist License" on a Google Business account.

No matter what I do on my paid subscription through Google Business with a Google Cloud project provided in the environment configured, which I had to explicitly set up just to test the CLI even though I have access to the Models through my subscription and AI Studio, I always get error 429 after one to five messages. The limits that Google claim on Gemini seem to be just a fraction of what is claimed in my case, No clearly stated reason as to why, not in the cloud console and not when using the tool itself, except for the HTTP error message.

These are not big prompts or anything of that nature. It's simple things like review a readme file or double check a single file for errors. It's been like this from the very beginning.

Even now just to verify it, I havent used Gemini for over a week, I ask it to review 3 files that are in git diff, the files are between 50-100 lines long, after checking the first file it's already on 429, on a PAID subscription, and it even states "99%" context left. So my paid subscription lets me use less than 1% of the context window and I get locked out for a unknown amount of time.

Contrasting this to both Codex and Claue Code, where you just log in and go, it's really a night and day difference. The user experience of the paid version of Gemini CLI is just utterly terrible.

Post reply on HN