Go Terminal_ Elegant and Efficient Linux Terminal
rungoterminal.comThere's literally nothing about this I like.
A terminal with a gradient background might look pretty for screenshots, but for long sessions it just adds to fatigue and makes text harder to read. "Saving your favorite commands" in a normal terminal involves writing an alias into your rc file, not a bunch of button clicks. Same goes for the whole "interactive flags" thing.
Whoever made this clearly hates the terminal and wanted to bring a hipstery web 2.0 approach to the terminal. My question is, WHY?
Oh, and it's PAID? Fuck that. Learn to use a proper terminal or don't bother, simple as that. That isn't me being a crotchety old timer, that's me giving you serious life advice. You will always be faster in the terminal if you learn to use it properly. a 2 hour tutorial in shell scripting and learning to use `man` is worth far more to your career than 10 bucks. Learn it the right way if you're going to bother.
</rant>
I have several devs in the office that have to use the terminal a grand total of 2 times a month, and even then I installed some shortcuts for them to make using adb easier.
Being able to build a simple interface on top of the few commands they use, so they don't have to remember flags, argument orders, etc., would be advantageous to us all (and require less support on my part).
Also, what is possibly wrong with someone trying to make some money for their work??
There's nothing inherently wrong with wanting to make money for your work. The problem, honestly, is that a good terminal is a solved problem (c.f. urxvt, which is perfect in every way). Charging people for one would be like charging people for a vim clone. Why charge for an inferior product when someone's already created perfection? ;)
Second of all, learning shell scripting is an almost ridiculously important skill. Wouldn't it be better that you sit those devs down and have them go through a couple hours of intensive shell boot camp so they don't need your help anymore? Anyone who's a halfway-decent dev can learn the basics of shell (simple scripting, variables, redirection, piping) within a couple of hours, easy.
To say the problem is solved you must first state it.
Maybe your terminal problem is solved (mine is), but their problem may be different.
Would you tell people who made chrome to quit back then, because the browser problem was solved? (IE, Opera, Mozilla Firefox) Or maybe tell Google to abandon drive and Microsoft onedrive and all that smaller companies like SugarSync to drop it because Dropbox has "solved it"?
This also means that indeed your previous question is good: it'd be nice if the author could explain the use case and business case for his terminal, seeing that we have a number of others around. (Google explained why Chrome with a comics thingy and got me immediately). But your questioning sounded like the author was already in err.
It's not that simple. The shell for you and me is muscle memory. For someone who takes a "boot camp" and then doesn't use what they've learned for 3 weeks, the boot camp was a waste of time.
Haven't you ever come back to a piece of code from a month ago and had to reacquaint yourself with it? (I know I can't be unique in that... ;) ) We cram an awful lot into our heads as devs, there's no room for things we barely use from a month ago.
To you, the shell may be perfect. For someone else, it's a severely antiquated method of input that was outdated after Windows 3.1.
I love me some shell, but that's you and me. Not all devs.
Edit: reminds me of CPR class. After a month or so, you better brush up lest you actually need to use it!
Here's what you do: in the middle of the night, sneak into all of your devs' offices and fuck with their xorg.conf's. Make them drop to command line only for a couple weeks (because we all know it takes at least that long to diagnose an xorg.conf....) and they'll learn. Oh they'll learn ;)
That's like saying you drop a modern human in the middle of the jungle, and tell em to survive for a week. I'm sure they'll "learn", or die trying but is that really a good way to do it?!
Or they'll quit. Oh they'll quit ;)
or, they'll just reinstall the OS, if they have decent backups.
you're a terrible person
I also kick puppies and write one word commit messages.
But I like them.
While I agree with you that urxvt is a great tool, I disagree with the suggestion that the terminal is "a solved problem" (or that vim is perfection). There is a lot of room for innovation, though not necessarily in the direction that Go Terminal is going.
I agree with each and every one of your comments; in addition, I would like to know how this project was created: what language it was made in, why the author found it necessary to create it, etc.
> what language it was made in
HTML + JavaScript + Electron
Just download that archive, extract its content, and you will find the "goterminal" script that is basically an ASAR archive [1] with a copy of CEF [2] as the webview for the web application that they (for some unknown reason) decided to create.
> that they (for some unknown reason) decided to create.
That's unpleasant. This is a forum for programmers. Care to explain why you are criticizing a participant for programming?
I see at least two possible reasons to create such a terminal: One: The author might have problems with how other terminals work. The other: The author just wanted to create something, without providing a superior value proposition. If it is indeed the latter scenario, it just wastes others' time.
> If it is indeed the latter scenario, it just wastes others' time.
What an absurd, and disgusting, point of view. The author is free to create whatever the fuck he/she wants, for fun. It's not wasting anyone's time -- no one else is obliged to spend any time interacting with it in any way.
You should really reconsider your position. One point is that, while you may have the skills and experience to only work on projects that improve the status quo, many of us do not; and even those who do, as beginners had to pass through the stage where they did not.
If a project does not improve the status quo, I think it should not be presented as something one “should have”.
The time wasted is exactly the time it takes to find out that “elegant and efficient” is at best hyperbole, at worst a lie.
Have you ever met a novice programmer?
> HTML + JavaScript + Electron
flips over table
Actually, let me unflip that table.
I am desperate for someone to come along and realize that the current terminal interface is a perpetual train wreck, and that if we can break compatibility but end up with something better we should.
Consider for a moment what a monumental task it is to make a simple ncurses menu and status bar in bash script. Consider for a second how trivial that could be made if each command line entry were a small flexible webview.
Imagine if you typed netstat and it showed the results, but there was also a field where you could key in text narrowing queries as part of the standard presentation for all very long input. No more appealing to grep or more and losing context or blasting your scrollback buffer.
Consider for a moment if we could move away from trivial line interfaces for SSH and towards a protocol that actually handles sessions and works over SSL in every conceivable network environment. Hell, most people I know have migrated to mosh and only type ssh when they're provisioning fresh cloud instances (usually to get mosh on there as fast as humanly possible).
The entire idea that "text is a superior interface" is correct as an input mechanism, but not necessarily as a data presentation mechanism. HTML and some basic es2015/typescript/whatever isn't just flat out better than bash for this sort of thing, but it flows from a long history of tools like tcl/tk trying to make the shell a more efficient and effective place to visualize trivial data.
I've been using terminals since 80 characters was a luxury and amber was the fancy new color, and for at least 20 of those years I've been hoping we'll see something that keeps the composability of shell scripting but introduces a non-line oriented protocol that could also offer presentation logic when appropriate.
We could preserve all of that if we just pretend all existing shell commands return a (forgive the templating syntax, it'll be understandable by a wide audience) Map<Stream<Text>> where {'stdout': <stdout>} and additional data can be offered around that with trivial API additions.
Please, let's not pretend we'd not benefit massively from richer tooling here.
> Please, let's not pretend we'd not benefit massively from richer tooling here.
Absolutely nothing about this project or the way they went about building it shows any tendency towards richer tooling. A web interface also does not inherently enable richer tooling. You could implement this non-line oriented protocol entirely without 500+ MB of JS and the interpretation of that data could obviously be done without it too.
Edit:
While I understand your rants all over these threads (it doesn't inherently have to be inefficient and bloated), you've picked a strange submission to take these fights in. The software in question is in fact bloated, not compliant and is really only an interface to aliases.
Also, I would add: The proof is in the pudding. You seem to have made this a personal crusade, so I would urge you to make a decent PoC with these ideas to show the world.
> you've picked a strange submission to take these fights in.
I don't see how that's germane. I didn't object to concrete references to the software (which is not as good as other submissions). I objected to knee-jerk silverbacking.
> You seem to have made this a personal crusade,
No, but I am so tired of people on HN mimicking the style of development we put together in the 80's and 90's because... well I have my opinions about this practice, but they're uncharitable. We'll leave it at that.
There is a cult of terminals in our industry that has fundamentally missed why terminals were an effective interface and throw shade on anything that isn't a terminal, even when it's actually a refinement on the terminal concepts.
> Consider for a moment what a monumental task it is to make a simple ncurses menu and status bar in bash script.
It really isn't, see e.g. whiptail.
And using ncurses for anything today is not a good idea. Surviving terminals are overwhelmingly ANSI, and can be supported by a single codebase that uses escape sequences directly, wihtout the horrors of ncurses.
I have seen whiptail. It's still easier to make a list of selectable options in html or markdown.
In your vision where text is not the universal interface, how would Unix pipes work? After all, often the output of one tool is the input of another – that usually has not been written to interact with the first.
Powershell accomplishes this by making the pipes pass tagged objects around containing streams. This actually has a lot of nice properties when you go to manipulate the objects programatically.
And it's a logical extension of the UNIX stream model, where in reality you're passing around a whole heck of a lot more than text when you type 'cat | sed'. You're passing environment context, multiple streams, etc.
The idea that this is "more complex" than unix pipes is understandable, but the reality is that IPC is pretty complex and a whole lot of magic and shared expectations go into the "simplicity" that bash offers. And even then that model breaks down all the time (e.g., as Docker becomes common as a deploy target the idea that you should output error conditions to STDERR has rapidly become problematic).
I do not understand what is the problem when using Docker. Please explain?
It's somewhat involved, but life is a lot easier if your Docker containers just log everything to stdout, when you go to ship software that uses them.
Stderr is sort of an annoying detail. Especially given how inconsistent output to it is and how it has different rules for how output flushes.
How do you imagine scrollback/ history on such thing? Genuinely curious. Have seen a few projects attempting this, but having all of the output searchable is a very central feature of terminal, for me.
Yikes. Thats a great way to make a terminal into a memory hog and unresponsive under load.
Oh?
Historically most terminal implementations have been fraught with performance issues. We'd moved off xterm to aterm and then back. We'd been hesitant to adopt gnome-terminal because of the GTK+ chrome then saw its font kit actually rendered faster.
What most people don't get is how absurdly well-optimized the text rendering and reflowing is for web browsers. With care, people can get modern cellphone browsers to hit 60fps animations and reflows while pushing huge volumes of text through them.
Take any 3 GUI toolkits you can name and ask yourself, "Do all three of these combined have a maintenance budget that equals that of even Firefox by itself, let alone any TWO modern web browsers?" Hell, some of the most cutting edge research into interpreters and garbage collectors is coming out of Google making V8 fast.
Quite frankly, I'd bet that with care and foresight this could be faster than iTerm.
Maybe I am wrong, but I have yet to see a modern browser take anywhere near as little memory of CPU as a modern terminal emulator.
There is also the matter that no matter how much optimization you put into something you can't recoup the cost of the fundamental design choices you went with. Choosing something with less power can solve a lot of headaches.
> little memory of CPU as a modern terminal emulator.
Browser instances can be quite svelte. But uh... I mean... shared lib pages tend to be actually shared pages. That's why the physical memory for multiple browser instances is a lot lower.
What's more, I'd gladly pay a higher price for a richer experience. We no longer need to or should rely on ANSI interfaces. In fact, they're becoming increasingly awkward in a world that really wants endpoints to be stateless by design rather than stateful sockets.
Many people have already discarded the single socket model oh SSH in favor of Mosh. Let's also ditch the console for all but the most basic of tasks. It's not 1997, the lingering stink of proprietary rich client environments is cleansed. Web browsers have annihilated that assumption and made something truly open and pretty amazing.
I use a web browser as my core text editor and I miss emacs not a whit and quite honestly it feels more responsive than my emacs setup. I don't notice any tangible performance differences from Vim in a terminal.
We can do better.
What machine are you running your terminals in? I have as little as 8 GB of RAM, and more CPU power than I could dream a decade ago.
Don't you think that maybe you are using your past environment to judge a current experience?
Visual Studio Code is based on Electron and works wonderfully. Doesn't feel bloated, it's quite fast to open and I haven't felt a slow down in any meaningful way.
I'm not imposing my computer specs to anyone (and I'm using vs code in a client machine in any case), but we have generally a lot more horsepower now and the discussion of performance might mean little for a desktop app (heck, we are running javascript on the server nowadays!).
So, everything you do on a computer is instant? Oh, it's not? Could it be because all those little inefficiencies add up to a big slow mess when all programmers operate under the assumption "oh I have 8GB RAM all to myself, no need to write efficient code!"
Oh god, the last software I'd want to be running a terminal in!
>HTML + JavaScript + Electron
This was my creeping suspicion the moment I saw the screenshots. Utter garbage.
I'm cringing at that entire paragraph.
I'm cringing.
> why the author found it necessary to create it
That's unpleasant. This is a forum for programmers. Care to explain why you are criticizing a participant for programming?
You seem to have made this about you, which is fine, but why should we care what _you_ like? Are you a person whose opinion is deeply valued and sought after? Because if you are, then certainly a subjective statement will be weighted by the knowledge, experience and the expertise of the person saying it. So my question is, why does it bother _YOU_ if someone, somewhere, finds value in this and prefers this to whatever other way you think other people should do it?
This isn't Facebook or Reddit. This is HN. Anybody trying to pass that thing off in this community has got some criticism coming.
It's a paid terminal emulator, written (by all appearances) in some kind of Electron-like (so a much much higher footprint), with a GUI for what can already be done via aliases, functions, and scripts.
And no telling how well $TERM detection works (show me vim! Show me something that wants 256 colors!)
If it was free, I might still not use it, because my terminal emulator needs to be lightweight and bulletproof, not heavy and shiny. A terminal emulator is a hammer -- simple, solid, good for constant use -- not an art piece.
This is how Emacs looks in it - http://imgur.com/E6cLkoF . Turning off the theme I am using fixes it, but many emacs shortcuts don't work.
I think you missed the gigantic "Download" button you see when you first open up the page.
That said, probably still won't use it. Too much whitespace and too shiny for my liking
So I can download it for free, or I can buy "1 year free update" for $10.
They need a much better explanation of what exactly I'm paying for, and what I'm limited to with the free version.
Just what I've always wanted from a terminal - things I can only do with a GUI and mouse. /sarcasm
This product seems to fundamentally misunderstand people that use terminals. Perhaps it would do better to instead become more of a thing that puts quick GUI wrappers around terminal commands and tries to parse the output and present it in a pretty GUI way for people who'd prefer not to get their hands dirty? Otherwise, this seems like what aliases and functions in my bashrc are for.
Either way, why is there a group of people that seems to think we desperately need to take applications that we are already running natively, wrap them in HTML/CSS/JS, throw them inside of a webview, embed that webview into a separate Chromium instance, and string it all together using a tool and execution environment designed to take a client-side single threaded web scripting language and use it for making servers? (Mugatu: I feel like I'm taking crazy pills - does nobody see this?!?)
> why is there a group of people that [want to wrap everything] in HTML/CSS/JS
I believe you already know the answer to your own question, because to be honest I think the answer is pretty obvious; but in case you are actually curious about the answer here is what I think (mostly sarcasm, don't expect much):
The majority of people making these applications are web developers who are frustrated by the difficulty of learning one or more of the popular GUI libraries available in the market (Cocoa, QT, GTK, etc), they found Node-Webkit and then Electron and realized that they could target desktop users using the same stack they have been using so far (HTML + CSS + JavaScript). Since they are web developers and many of them were originally designers, it is makes sense to think that they can make shiny websites to attract people into trying their projects.
I think most of these programmers just want to show up, try this new Electron thing, and get acknowledged by other people. I don't think they believe their applications are actually good because it is obvious that they are not (as in this case). As much as I hate this trend of web applications disguising themselves as (native) desktop application I have to agree that Electron have allowed some people to... Hmmm, you know what? I don't think Electron has allowed anyone (with the exception of GitHub) to accomplish anything, fuck that trend.
Well there's Slack and VS Code just off the top of my head
Slack started as a website, then created the desktop and mobile clients, so if I stick to my statement "accomplish anything" I would still keep Slack out of the list because the "desktop" client does not provides anything special over the original web interface. About Visual Studio Code, I don't know what have Microsoft accomplished with that project yet, but I will give you a point for that just because.
> Just what I've always wanted from a terminal - things I can only do with a GUI and mouse. /sarcasm
Just what this conversation needs - someone who fundamentally doesn't get that web browsers and their derivatives have more affordances for accessibility than a native terminal interface ever did.
> This product seems to fundamentally misunderstand people that use terminals.
> Either way, why is there a group of people that seems to think we desperately need to take applications that we are already running natively, wrap them in HTML/CSS/JS, throw them inside of a webview, embed that webview into a separate Chromium instance, and string it all together using a tool and execution environment designed to take a client-side single threaded web scripting language and use it for making servers? (Mugatu: I feel like I'm taking crazy pills - does nobody see this?!?)
In part because this could offer secondary visualizations for data that is better without breaking anything at all, if people would stop making elaborate nose-pinching brow arching gestures every time the idea of a web browser came up.
Oh, and it'd be the basis for a more robust and usable SSH option. SSH is a horrible protocol and Mosh works in very few network environments. An HTTP/2 connection and decoupling of input from user response (without appealing to line mode) would be demonstrably better.
> Just what this conversation needs - someone who fundamentally doesn't get that web browsers and their derivatives have more affordances for accessibility than a native terminal interface ever did.
I do not have sight impairment, but I'm quite certain that I could navigate a fixed number of keystrokes more reliably than I could operate a mouse. If I were listening to synthesized speech dictating on-screen output, I know that the option that makes the most sense is four taps back and one up. Finding that with a mouse would be unnecessarily complex by comparison.
I don't understand why you're perfectly happy to consider assistive technology for your terminal but completely unwilling to consider assistive technology for the browser.
The Web is an order of magnitude more tooled for usability than nearly any application you use on a day to day basis. Requiring pointer actions has nothing to do with that.
This appears superficial, and that this is paid as well with no (visible) published open source turns me off. The mistakes in the GIF communicate that this was a slapped-together product.
Additionally, requiring mouse clicks for a visual replacement of the alias command with a few extra bells and whistles is not the greatest appeal to a community of developers.
I hope that the fact that this was written in Go does not outweigh its shortcomings in the eyes of HN.
Don't be fooled by the name, this application is not written in Go, that is just a random word that they chose for the name. The application was written in HTML and bundled with a webview powered by CEF (probably Electron). Just download the application and execute `strings goterminal | grep chromium` and you will see what I am talking about; again, this has 0% Go code.
EDIT: Here is the list of 720 NPM packages used by this: http://pastebin.com/raw/VhnuuDdX
EDIT2: To rub salt into the wound, this thing is ~620MB of HTML + JS + Electron, that is more or less how an entire Ubuntu installation was six years ago, like really? An entire basic Linux installation could have been included in all this archive and these guys decided to fill it with JavaScript code. Isn't a terminal emulator supposed to be lightweight?
> this thing is ~620MB of HTML + JS + Electron
Is it 620MB of source text? I'm not a web guy, so I literally I can't understand this, unless, since it's a web tech, 30 minutes of cat videos are required in the source.
Yes and no; there are some binary files too, but there are ~534MB of JavaScript code mixed with additional assets. Once you extract the content from the archive (using the tar.gz version) you will find a directory with multiple sub-directories and files that roughtly weighs 636MB distributed like this:
The directory "resources" contains the ASAR file plus another sub-directory named "app" that contains the assets and the "node_modules" tree, this directory alone weighs 534MB because of the 720 NPM packages required by the application.9.1M - content_shell.pak 60M - goterminal 9.8M - icudtl.dat 4.0K - INSTALL 2.5M - libffmpeg.so 18M - libnode.so 20K - LICENSE 352K - locales 404K - natives_blob.bin 536M - resources 604K - snapshot_blob.bin
720 npm packages..........................................
Guess the chances that it won't built anymore in 1 week are 99.9%.
Amusing idea, and this kind of "quick GUI-builder" mechanism reminds me of ifttt or zapier in the way it gives more scripting/glue power to people who normally have access to less of it. And this would be useful for a mobile or tablet application, where GUI shortcuts to save typing help a great deal.
But the demo video shows one major issue that breaks its primary functionality as a terminal: the font rendering has a vertical spacing problem going on, with lines 1.5x spaced, which would break many screen-oriented applications, especially those that use line-drawing characters. Notice how at 22s into the video (https://www.youtube.com/watch?v=XbDxvJn1jV0#t=22s), the inverse-colored character shortcuts at the bottom of nano's UI have space between the white boxes; the white boxes should touch, like this: https://imgur.com/q0TERnM
This is either a bug with the terminal itself, or a bug with the font used. I looked for a bug tracker to report the bug, at which point I noticed that it wasn't FOSS, and promptly lost all interest in taking the time to make such a report.
Also, while I realize that this uses a browser engine for its UI, there's something surreal about a terminal emulator bundling libffmpeg.so.
This isn't even a decent terminal emulator in the basic ways. It has an enormous memory footprint, abysmal compatibility, and very little in the way of novel features to offer.
If you use a better shell (like fish) it leaves this even less appealing. I'm sure this took some work to do, but I don't know anyone with a job to pay for it, which would use it.
The word "efficient" describes the exact opposite of what this is.
In addition to all of that, the package includes all of the build-time dependencies with it. And the package they use for the terminal emulator part of it is explicitly abandoned by its author (https://github.com/chjj/term.js/)
Nobody should pay 10 dollars(let alone 20 dollars for limited ongoing support) for more than half a gigabyte of unmaintained, deprecated open source code, plus about 2000SLOC of proprietary code for a sidebar which does something which is basically already built into the shell.
Also, there is no clear roadmap for this; so it's totally unclear what "3 years of updates" means when half of the thing is deprecated and it hasn't even left beta!
If you're like me, you'll think, "aliases!"
But, the shell is a bunch of nontrivial things to learn. Tools like Go Terminal_ could make a less discontinuous learning path for shell. I recently had to teach[0] someone a bit of shell, and I kept tripping over explanations of:
command -[flags] arg1 arg2 arg3 | something else
All that said, I wouldn't call Go Terminal_ "efficient" ;).
[0] I did a terrible job.
> But, the shell is a bunch of nontrivial things to learn.
Yeah but if you're gonna learn this trade, you kinda gotta learn these things eventually, so why settle for a pacifier indefinitely?
I should have been more explicit. I'm wishing for a less discontinuous shell-learning-path, meaning to say that you'd stick with Go Terminal_ until you found you wanted something that zsh or tmux or whatever offered you.
Everything I've learned in programming I've learned that way: do something the repetitive way until I notice it, then research or do something better.
Interesting concept, but I'm not sure who this is directed towards. I can see some people using this, but not that much. (experienced) Developers will naturally go towards the features that shells like bash/zsh offer (e.g. aliases), and most inexperienced developers... well, I don't see them putting that much effort into configuring their terminal, and besides this, most people in the Linux world will hardly pay for something that they can get for free from somewhere else, unless it really is a necessity, which doesn't seem to be the case here. That said, I wish you the best on that. Always good to see different stuff.
I was trying to install this .deb package with ubuntu software center. My system warns with the below message.
"This package is of bad quality:
The installation of a package which violates the quality standards isn't allowed. This could cause serious problems on your computer. Please contact the person or organisation who provided this package file and include the details beneath.
The package doesn't provide a valid Installed-Size control field. See Debian Policy 5.6.20."
You've been lambasted!
While I agree with pretty much all the criticisms raised by others, I would just like to qualify that I like the idea of attempting to disrupt the traditional terminal.
A terminal will always be a window from GUI land to the shell, but that doesn't mean we can't play with it! :)
In my experience, terminals like xterm and rxvt ran extremely efficiently on machines 23 years ago, like, oh, a 66 MHz 486 DX2 with 8 Mb RAM. I can't say that I ever had a complaint with the speed of scrolling, or rendering of characters, or general responsiveness.
Looks like a visual version for an alias list.
Here are somethings which might be more substantial improvements.
A status bar which helps in understanding what a command does. So you type 'command -xva a b' and the status bar gives an English description that the command is going to do such and such(based on flags) on files a and b.
Simple discoverability like an interactive version of reading man pages or apropos, where after typing something like git or ls, the user who doesn't remember the exact options, can press some shortcut and type a english description like 'hidden files' 'reset' and the status bar displays the relevant flags and their description. This kind of semantic autocomplete, would save a visit to a long man page.
Why is the download 100MB big ? Isn't it a bit heavy for a simple terminal ?
Because it bundles Electron [1] which weighs (for version 1.2.6) around ~40MB, if you also include the size of the 720 NPM packages [2] that this application uses then you get the same size that you are complaining about. However, if you also extract the content of the archive you will notice that it actually weighs ~620MB LOL.
[1] https://github.com/electron/electron/releases/tag/v1.2.6
Is this some type of sponsored post shit?
I don't know how much of an advancement this is for a seasoned user, but I do think this would be a great learning tool since you can visually see all the commands generated by the terminal.
That's what shines in my eyes from this project.
I might not see a developer using this, but an administrator I could. Needing to run one-off scripts and server management. However only if it would work remotely, and with host specific configuration and command options.
Not to be "that guy", but if I saw an administrator using this, I would sit them down and show them the magic of using a real shell(tm). I mean, seriously, if you're a computing professional, and you're using a shell on a daily basis, this is an embarrassingly silly crutch to use. Setting up aliases is no more difficult than using this....thing, and instantly useable over ssh or copyable to other machines. Fo' free. Just saying.
The proper response to seeing a systems administrator using one-off scripts from his workstation to manage systems is to fire him immediately and hire someone competent.
Right, because any sysadmin worth his salt is going to embed that ugly hack right into the infrastructure for all eternity.
IMO, it makes no sense.
alias is free