5 ms·

> arcane insertions into ones .bashrc Are there particular changes to .bashrc that you think are arcane, or do you mean that any change to .bashrc is arcane?

by DougBTX 15y ago

seclorum 15y ago
Just the idea that the installation of an "app development environment" starts with modifying my bashrc, and thus my entire shell, bothers me. This may not be a rational fear, but as a crufty old Unix guy, it a 'smell' to me. Its just not clean - there are too many opportunities to have something end up in there that breaks something else. My .bashrc is not an /etc. I know, I know .. there is no other way to have a fully super-duper shell environment with pretty colors and notifications and other .. GUI-like elements .. without tweaking my prompts and touching my vars and so on. But, hey .. couldn't the same concept be built up as a real application, after all, which spawns its own shell and leaves my system defaults alone ..
- shabble 15y ago
  it would be relatively easy (and I'd be surprised if someone hadn't scripted it to make it easier) to have a set of project specific configs which you merge into your global configs and exec a subshell per project. If you did it inside screen/tmux then you'd be able to switch between them easily as well. The main issue I have with discriminating shells like this is that I tend to have a whole bunch open, and use the first I find that isn't already doing something useful. This means a lot of the time it's using features that technically 'belong' to a different project.
- DougBTX 15y ago
  Yes, fair point. That's a good argument for using the git-number plugin instead, which has similar core features. The scm_breeze plugin didn't seem to like my hostile Cygwin environment, I'll try out git-number tomorrow, it should be a bit easier to get working. At first I was put off because I didn't know where it was putting its state. I see now that it is a text file in the .git directory, which on reflection is neater than the environment variables scm_breeze uses.

> arcane insertions into ones .bashrc Are there particular changes to .bashrc that you think are arcane, or do you mean that any change to .bashrc is arcane?

by DougBTX 15y ago

> arcane insertions into ones .bashrc Are there particular changes to .bashrc that you think are arcane, or do you mean that any change to .bashrc is arcane?

seclorum 15y ago

Just the idea that the installation of an "app development environment" starts with modifying my bashrc, and thus my entire shell, bothers me. This may not be a rational fear, but as a crufty old Unix guy, it a 'smell' to me. Its just not clean - there are too many opportunities to have something end up in there that breaks something else. My .bashrc is not an /etc. I know, I know .. there is no other way to have a fully super-duper shell environment with pretty colors and notifications and other .. GUI-like elements .. without tweaking my prompts and touching my vars and so on. But, hey .. couldn't the same concept be built up as a real application, after all, which spawns its own shell and leaves my system defaults alone ..

shabble 15y ago
it would be relatively easy (and I'd be surprised if someone hadn't scripted it to make it easier) to have a set of project specific configs which you merge into your global configs and exec a subshell per project. If you did it inside screen/tmux then you'd be able to switch between them easily as well. The main issue I have with discriminating shells like this is that I tend to have a whole bunch open, and use the first I find that isn't already doing something useful. This means a lot of the time it's using features that technically 'belong' to a different project.
DougBTX 15y ago
Yes, fair point. That's a good argument for using the git-number plugin instead, which has similar core features. The scm_breeze plugin didn't seem to like my hostile Cygwin environment, I'll try out git-number tomorrow, it should be a bit easier to get working. At first I was put off because I didn't know where it was putting its state. I see now that it is a text file in the .git directory, which on reflection is neater than the environment variables scm_breeze uses.