Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You can simply add a shell alias with whatever name you like and move on.


True, but easier said than done, because one often need to work in more shells than their local machines..


This is a nonstandard tool. If you can't customize your machine, you already don't have it.


But it could be one day..


Do something like this to fall back to plain grep. You will somehow have to share these configurations across machines though.

    alias g=grep
    command -v rg 2>&1/dev/null && alias g=rg


Sixty-six words about capitalizing things properly and you think this is something that learning about shell aliases can solve. Impressive.


You can't in most corporate env machines.

You may be able to download ripgrep, and execute it (!), but god forbid you can create an alias in your shell in a persistant manner.


> You can't in most corporate env machines.

Really? "most" even? What CAN you do if you can't edit files in your own $HOME?


`[citation needed]`


huh? If you can download and execute files, you can alias it. Either in your .bashrc file, or by making a symlink.


I daily drive linux, but I hop from clients to clients and I have probably served about 200 different structures so far.

Most corporate machines are Windows boxes with ps and cmd.exe heavily restricted, no admin, and anti malware software surveilling I/O like a hawk.

You might get a git bash if you are lucky, but it's usually so slow it's completely unusable.

In one client I once tried to sneak in Clink. Flagged instantly by security and reported to HR.

It's easy to forget that life outside the HN bubble is still stuck there.


How can you possibly get development work done in an environment where you can even make a Microsoft.PowerShell_profile.ps1?


You will be even more horrified to learn that installing the entire list of deps of a project that would take a few seconds on my home laptop may take up to 20 minutes at some clients because many FS calls do a network round-trip.

We are not talking about exceptions either. This is pretty standard stuff when you work outside of the IT-literate companies.

At one client, they provided me with a part time tester, they neglected to give him the permissions to install git. Took 3 weeks to fix.

The same client makes us dev on Windows machine but deploy on Linux pods. We can't directly test on the linux, nor connect to them, only deploy on it. In fact, we don't even have the specs of the pods, I had to create a whole API endpoint in the project just to be able to fetch them.

Other things I got to enjoy:

- CTO storing the passwords of all the servers in an libre office file

- lead testing in prod, as root, by copying files through ftp. No version control.

- sysadmin that had an interesting way of managing his servers: he remote controlled one particular windows machine using team viewer which ones the only one that could connect through ssh to them.

The list is quite long.

This makes you see the entire world with a whole new perspective.

I always thought that all devs should spend a year doing tech support for a variety of companies so that they get a reality check on what most humans actually have to deal with when working on a computer.

If you are on HN, you are the 1%.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: