Command Line vs. GUI on Linux

tharpa

For those who use Linux (and other Unix-related OS's), if you can use either the command-line or a GUI, do you always pick the command-line, or do you sometimes pick the GUI?

If I can use either, I will generally use a GUI, but I find that most of my co-workers prefer the command-line.

Windows users can respond as well, but I suspect that it will weigh much heavier on the GUI side.

stillwater

What do you mean Linux GUI? Use it for general tasks or programming tasks?

cvi

Generally command line. Exceptions for stuff like one-off image editing even if that would be doable with imagemagick et al., and other graphics-heavy tasks (dealing with 3d models and so on).

tharpa

@stillwater said in Command Line vs. GUI on Linux:

What do you mean Linux GUI? Use it for general tasks or programming tasks?

Both, actually. (Though it may have different answers.)

Gąska

@tharpa depends on whether GUI tool or CLI tool sucks less. And shitty CLI is easier to work around by piling layers of scripts on top of it than shitty GUI.

stillwater

@tharpa I tend to use the UI for folder navigation mostly and CLI for everything else cos everyody has a fucking boner for CLI on Linux and only talk about doing things the CLI way. Also I find the Linux UI (Ubuntu mostly) very jarring.

EDIT: I'm a window user and never use CLI on Windows. On Linux I need to :/

TwelveBaud

I use Synaptic for package management and GTParted for partition management, since those GUIs are actually good and provide a lot of assistance -- the former because it adds a lot of visual cues, similar to Aptitude but better presented, the latter because it eliminates typing errors from a batch of several very dangerous commands -- but otherwise I tend to use the CLI.

Cursorkeys

@tharpa Generally command line and I do prefer that for nearly everything (some systems have no display server so it's CLI only there). I do use GUI file management tools as I hate navigating folder trees via the CLI, so SCP on the display-server-less systems and whatever file manager is available on the others.

Carnage

Varies for different tasks.
With git, for example, I usually do diffs and watch complex branch graphs in GUIs, but I do the vast majority of everything else with git in CLI, like commits, branching merges and cherrypicking and the like.

Some things are simpler with a GUI, while others are made harder because it leads to lots of fiddling in various tabs and crap, where a single line in a CLI will do the job perfectly.

Adynathos

@tharpa I use Ubuntu with KDE, I prefer to use the GUI when one is available for a given task:

file management (including mounting directories over sftp:// instead of using scp)
system settings
searching for packages muon
git: diffs and commiting with gitg, i wish there was something better though
running python with jupyter
Blender - 3D model editing
Inkscape / Krita - 2D image editing
x2go - remote desktop (but has to be installed on the server)
CMake GUI

Sadly, there are many areas where I can not find satisfying GUI programs:

ffmpeg for audio and video conversion
ssh to a server without graphics and x2go
htop to see cpu/mem usage on these servers
git: push/pull/fetch/rebase
conda package manager for python
building stuff from source

Gurth

@tharpa said in Command Line vs. GUI on Linux:

For those who use Linux (and other Unix-related OS's), if you can use either the command-line or a GUI, do you always pick the command-line, or do you sometimes pick the GUI?

Depends on what I want to do. Quickly copy a file, I use the Finder (I’m talking about macOS here); quickly (relatively anyway) copy a thousand files, especially to another drive, I usually use the command line, because the Finder tends to be hideously slow for that kind of thing.

Gąska

@adynathos let's see how my Ubuntu usage compares with yours...

file management (including mounting directories over sftp:// instead of using scp)

Same here, with the exception of making symlinks or going through system config files (it's MUCH faster to type /etc/fewletters<tab> than navigate there in GUI).

system settings

Depends if I google up a GUI tutorial or a CLI tutorial first. Never tried doing anything without checking out tutorial first.

searching for packages muon

I'd use GUI too, if not for the fact most packages can't be found in GUI. Also, GUI updater uses package description instead of package name, and most descriptions don't include program name, so I never actually know what I'm updating (but it doesn't matter since I always update everything).

git: diffs and commiting with gitg, i wish there was something better though

I've become proficient in reading raw diffs. But for merging, I always use GUI (first one I can get my hands on; they all suck about as much).

running python with jupyter

Blender - 3D model editing

Inkscape / Krita - 2D image editing

x2go - remote desktop (but has to be installed on the server)

N/A

CMake GUI

Same, although I only ever used CMake on Windows.

ssh to a server without graphics and x2go

htop to see cpu/mem usage on these servers

Same, but it shouldn't be included in this list since GUI isn't even an option at all.

git: push/pull/fetch/rebase

Same.

conda package manager for python

N/A

building stuff from source

Same.

blakeyrat

@gąska said in Command Line vs. GUI on Linux:

ssh to a server without graphics and x2go
htop to see cpu/mem usage on these servers

Same, but it shouldn't be included in this list since GUI isn't even an option at all.

Windows has GUI versions of both of those. And I know Linux has VNC (and there are Linux implementations of Microsoft's RDP.)

Gąska

@blakeyrat if your car has no LPG tank, fueling it up with LPG isn't an option even if there is LPG pump right next to you. If your server has no GUI, using GUI on it isn't an option even if the server right next to it has. You could argue that they should get a server that does have GUI in the first place, but for most people, deciding on their work environment isn't an option either.

PJH

@tharpa said in Command Line vs. GUI on Linux:

if you can use either the command-line or a GUI, do you always pick the command-line, or do you sometimes pick the GUI?

Whichever's the easiest for me.

Editing ~/.ssh/config, vi or nano. Editing source code, Kate.

Git/SVN within one branch, generally CLI. Cross-branch stuff, GUI.

etc.

blakeyrat

@gąska said in Command Line vs. GUI on Linux:

If your server has no GUI, using GUI on it isn't an option even if the server right next to it has.

Well fair enough, but that's not Linux making that decision. So the way you phrased it is kind of misleading.

@gąska said in Command Line vs. GUI on Linux:

You could argue that they should get a server that does have GUI in the first place,

I'd argue that:

The reasons Linux admins have for leaving out the GUI don't make much sense
The only tiny bits of sense they make aren't due to any inherent properties of GUIs but because Linux has worse memory management (Windows will swap out 100% of the GUI if it's not being used on a server) and less-tested and less-secure GUI libraries than competing OSes (Windows won't get pwned through the login screen)

But that's off-topic.

Gąska

@blakeyrat said in Command Line vs. GUI on Linux:

@gąska said in Command Line vs. GUI on Linux:

If your server has no GUI, using GUI on it isn't an option even if the server right next to it has.

Well fair enough, but that's not Linux making that decision. So the way you phrased it is kind of misleading.

There's a reason I said "server" and not "system". This particular installation on this particular machine has no GUI.

@gąska said in Command Line vs. GUI on Linux:

You could argue that they should get a server that does have GUI in the first place,

I'd argue that:

The reasons Linux admins have for leaving out the GUI don't make much sense

People in charge have no fucking clue what they're doing. News at 11.

HardwareGeek

CLI for most things. gvim for editing, because switching back and forth between files is easier, and because mouse support doesn't always work in terminal window vim. tkdiff because understanding what has actually changed is easier in the context of the whole file than looking at only the changes (with, perhaps, a few lines of context); the color highlighting is nice, too. At the moment, p4v because the CLI version has decided that my workspace is not a valid workspace, but the GUI works fine. Programs that are inherently GUI, like the IDE (if you can call it that). Very rarely, the file manager. Other than those, CLI for just about everything.

mott555

For personal Linux machines, it's pretty much all GUI (general computing, e.g. web browsers and music players). At work, it's 100% CLI.

LB_

I use command line interfaces exclusively for tools related to compiling or controlling code. So, CMake and git and gcc/clang (though I use VS for MSVC). Everything else either doesn't have a CLI or the CLI is worse. This applies to both linux and Windows, for me anyway.

Not really a fan of apt-get, I try to use the GUI package manager if I can but I often have to resort to apt-get.

pie_flavor

Linux has a GUI?

ben_lubar

@carnage said in Command Line vs. GUI on Linux:

With git, for example, I usually do diffs and watch complex branch graphs in GUIs, but I do the vast majority of everything else with git in CLI, like commits, branching merges and cherrypicking and the like.

I'm the exact opposite of you. I cannot do complicated git stuff in GUIs. I need the command line for that.

HardwareGeek

@ben_lubar said in Command Line vs. GUI on Linux:

I cannot do complicated git stuff ~~in GUIs~~.

FTFM. Heck, I have trouble doing simple git stuff. I've only been using it off and on for a couple of months, and I still forget to push after committing.

Kian

I have an Ubuntu machine for work, and I use GUI tools when possible. A great deal of my job is automating processes though, dealing with make files and shell scripts, so I spend a lot of time in the terminal testing.

pie_flavor

@kian said in Command Line vs. GUI on Linux:

she'll scripts,

Kian

@pie_flavor Duck my phone's auto complete.

bb36e

I use the command line for installing updates and running scripts (eg I script media transcoding for new albums). GUI for everything else. I haven't programmed in months.

dkf

@tharpa I mostly use the command line (on OSX, no less) except for working with git, where I'll use a GUI if I possibly can because git…

[EDIT]: The choice of GUI matters here. Most GUIs for git are pretty miserable, and only let you do very simple things. Fortunately, the git GUI inside my IDE (Eclipse) is better than that, in that it lets me do really quite complex things from the history view. There's been a few cases where I've had to use the GUI (because I was doing a particularly evil merge, substantial history rewrite, or import from an especially fucked up old SVN server that was going away) but those were a mere handful of cases. For all normal developer activity across many branches and quite a bit of advanced stuff too, I've been just fine with Eclipse's GUI for git.

Many of my cow-orkers use JetBrains's GUIs instead. Those are not nearly as good at supporting git; you have to drop to the command line far more frequently there. (I don't work with enough people who use VS to comment on it.)

dfdub

@dkf said in Command Line vs. GUI on Linux:

Many of my cow-orkers use JetBrains's GUIs instead. Those are not nearly as good at supporting git; you have to drop to the command line far more frequently there.

Really? Can you name an example?

I use IntelliJ and derivatives for some of my projects and never leave the GUI for git stuff. Previously, I sometimes had to for partial commits, but they're now supported as well.

blakeyrat

@dfdub Might depend on what Git features you're using. Subrepositories were hard for GUI clients for a long time (not sure if they still are; the last two companies I've been with don't use them).

AFAIK, there's zero GUI clients that can handle precommit or postcommit hooks in a way more sophisticated than just echoing the text to the user in a dialog box.

bb36e

@dfdub I generally don't use graphical git clients because I'm afraid of change and don't want to bother learning how to map my knowledge of the command line version to the graphical version.

dfdub

@bb36e Trust me, once you've had a GUI assist you during a rebase, you never want to go back.

Onyx

Depends on the task at hand, mostly. I prefer using CLI to look for stuff (I'd kill for find and grep on Windows at times), manage file permissions, package management and such, but GUI for messing with stuff like networking since NetworkManager's GUI is pretty good.

I'm mostly in the "whatever is faster" camp. For example, zsh's tab completion is so darned good I find it faster to do even simple stuff like copying files faster in CLI if it's not something that's only one or two levels deep in directory tree.

mott555

@dfdub said in Command Line vs. GUI on Linux:

Trust me, once you've had a GUI assist you during a rebase, you never want to go back.

This sounds like dialogue from a porno version of CSI.

Gąska

@onyx said in Command Line vs. GUI on Linux:

I'd kill for find and grep on Windows at times

Windows Explorer search function has most of the functionality of Unix find command. And for simple CLI stuff, you can use dir or where. As for grep, you can find Windows version here.

mott555

@gąska AstroGrep is pretty useful on Windows.

AstroGrep

pie_flavor

@onyx said in Command Line vs. GUI on Linux:

(I'd kill for find and grep on Windows at times)

grep is Select-String. find can be done by piping Get-ChildItem to Select-Object.

Onyx

My point was not to harp on Windows here, I was just pointing out stuff I miss in GUI without specifically mentioning Nautilus, Nemo, Dolphin, Konqueror, Thunar, PcManFM and whatever else, but fine, I'll address it since everyone is poking at it:

There's pretty much not a single GUI file manager that can replace find, not because it sucks as searching, but because I can't pipe commands to it (though Thunar's bulk renamer is pretty damned good). I might have had to specify it better, but I didn't feel like going on a long winded tirade about being able to rename and move files in bulk by using find -exec
Installing extra stuff is fine on my machine, but it's not a standard system utility and I can't count on it being everywhere. *NIX grep is. If there's a distro without it installed, please burn it. With fire.
PowerShell... oh PowerShell, such a beautiful thing, the shell which no one I know can figure out and they figured out the atrocity that is bash in a few days. But you know, that's just lazy users, fuck that. You know why I just can't make myself use PowerShell? Because it's not usable as the main system shell until they fix their fucking paths!

0_1529002253540_70003727-21f5-4b2a-892e-79a00b75d10f-image.png

That's just one example of shit not working I know off the top of my head. I'm sure there's more.

Ok, I done, and I wow never to use the word Windows in even a slightly negative context ever again, lest I be educated again. I didn't even try to say CLI is better or anything. Goddamnit.

blakeyrat

@dfdub said in Command Line vs. GUI on Linux:

@bb36e Trust me, once you've had a GUI assist you during a rebase, you never want to go back.

Going back to Subversion or TFS is exactly what I want to do, even just hearing the word "rebase".

pie_flavor

@onyx

New-Item -Type HardLink -Value foo.txt -Path bar.txt

You're using a command from one shell in another shell. Why did you think that would work?

pie_flavor

@onyx said in Command Line vs. GUI on Linux:

Because it's not usable as the main system shell until they fix their fucking paths!

I really have no idea what you're talking about here. PowerShell paths are actually far better than cmd paths. For instance, you don't need an extra flag to cd if you're switching drive letters

Onyx

@pie_flavor oh, I forgot, it's all shell builtins here, because fuck being able to use them from something else if you need to. And they have been only partially ported, because yay consistency!

Anyway, I'm outta here, not interested in yet another OS flamewar in the least.

dkf

@dfdub said in Command Line vs. GUI on Linux:

Really? Can you name an example?

Let's see if I remember this right. (I emphasise that I've never ever liked a JetBrains GUI. They simply don't work in the way I think, and that's a recipe for frustration.)

Cow-orker does something dumb (adds a 10GB text output file to a commit) and the upstream server rejects the push. That's (part of) an entirely sane policy for Github to have; I'd do the same. So what to do? Easy: commit a delete of that file (and an update to the ignored files list so it doesn't happen again) and squash those commits together into one so the vast file is expunged. That'll let the branch be pushed up and the world will be happy once again.

I've literally no idea how to make the PyCharm GUI do this vital piece of fixing. Yes, we could do the simple part (adding the fix commit) but I couldn't work out how to squash things. It's a vital intermediate level piece of functionality. (I don't mind truly advanced stuff like complex imports from other systems being CLI only; that's pretty much at the point when you're writing a program to do the job anyway, albeit one with a few manual “stare at the config and see if it makes sense” steps in it.)

dfdub

@dkf said in Command Line vs. GUI on Linux:

Yes, we could do the simple part (adding the fix commit) but I couldn't work out how to squash things.

It's literally a checkbox in the commit dialog. I have no idea how you managed to miss it.

Edit: And if it's an old commit that you need to squash: Go to the history view, right click on the last good commit and click "Interactive rebase from here". (I don't remember the exact text, but that option exists.) Then you'll see a dialog listing all commits where you can move the fix commit down until it's next to the bad commit and mark it as a "fixup" (if you don't want to edit the commit message) or "squash" (if you want to edit the message).

HardwareGeek

@onyx said in Command Line vs. GUI on Linux:

For example, zsh's tab completion is so darned good I find it faster

Sometimes. Sometimes it tries too hard. I want to git add Makefile, where Makefile is the only file in the current directory that starts with M. If I forget and type git add M<tab>, I can go make myself a cup of tea while zsh apparently searches the whole workspace for anything else that starts with M. Most of the time, though, you're right; it's great.

HardwareGeek

@pie_flavor said in Command Line vs. GUI on Linux:

@onyx said in Command Line vs. GUI on Linux:

(I'd kill for find and grep on Windows at times)

grep is Select-String. find can be done by piping Get-ChildItem to Select-Object.

Too bad I don't use it often enough to remember the syntax, at all, without looking it up every single time.

admiral_p

GUI for whatever is sane to do in the GUI. Mostly interactive stuff or stuff that you could do in the CLI but would be unwieldy because of the million flags and parameters without having written a bespoke shell script beforehand (eg. re-encoding audio).
CLI for whatever has a very low degree of interactivity once you run the command, but at the same time it is easily tab completed by the shell. I'll edit files in gedit (not a snob) but I'll run gedit from the command line because it's actually faster.

pie_flavor

@onyx said in Command Line vs. GUI on Linux:

@pie_flavor oh, I forgot, it's all shell builtins here, because fuck being able to use them from something else if you need to. And they have been only partially ported, because yay consistency!

Anyway, I'm outta here, not interested in yet another OS flamewar in the least.

Not even an OS flamewar - you can use PowerShell for Linux.
And yes, cmd has as many builtins as powershell, except in powershell it's all on the .net runtime so you can call them from any C# program. That actually tops cmd because you have to start a cmd process in order to use the commands. Also, every single cmd command has an analog, if not a superior, in powershell so it's not 'partially ported' in the least.

pie_flavor

@hardwaregeek You just have to remember the verbs and that the common nouns are Item and Object. After that you can just tab complete everything.

HardwareGeek

@pie_flavor said in Command Line vs. GUI on Linux:

@hardwaregeek You just have to remember the verbs and that the common nouns are Item and Object. After that you can just tab complete everything.

I've probably used like 4 verbs, and I haven't even used them in months. I have Cygwin on my own desktop, so I have bash, which I know much more thoroughly than PowerShell, available any time I need it. At work, I do most of my real work on Linux. We use just about every scripting language known to mankind — except PowerShell.