3 ms·

1. A script that opens all of my morning apps and browser tabs in one command. 2. I make a run.sh script in every project that I add to my git exclude, so whet

1. A script that opens all of my morning apps and browser tabs in one command. 2. I make a run.sh script in every project that I add to my git exclude, so whether it's a Go app, Python app, Node app, makefiles, Docker, ..., no matter what I can go into any project and run this script to start it. Then I add an alias in my bash profile so I just type "r" to ./run.sh. For more complicated apps, I generalize this to have a build.sh, deploy.sh, etc.

jimktrains2 8y ago
I do something similar, but with make.
- tedmiston 8y ago
  I wanted to go this route but it felt weird in projects that already had makefiles committed in the repo used by others to have to name my Makefile something else and then run like: make -f Makefile2 build ... Is that what you do?
  - jimktrains2 8y ago
    I've never updated a repo with a make file and I needed to script things that didn't belong in the main make file. I'm not sure what I'd prefer to do.
masukomi 8y ago
... maybe this is crazy, but why not just name the script r and do away with the alias? that way your shell can let you know "hey that's not an executable in this dir" if you ever try and run it somewhere it isn't instead of "hell i'll run that alias for you... oh "
- tedmiston 8y ago
  The argument I have for keeping the .sh convention is to be able to go into an arbitrary project and run `ls *.sh` to see all of my commands.
  - komon 8y ago
    Ooh, sounds like an opportunity to alias `ls *.sh` to something handy to list your available commands. You could even format it pretty. I wonder if you could further play around by having your command aliases default to figuring out what sort of project you're in and either doing the nearest 'generic' method of completing that command for that type of project or perhaps even generating a skeleton file and opening up your $EDITOR to edit to fit the project you're in.

jimktrains2 8y ago

I do something similar, but with make.

tedmiston 8y ago
I wanted to go this route but it felt weird in projects that already had makefiles committed in the repo used by others to have to name my Makefile something else and then run like: make -f Makefile2 build ... Is that what you do?
- jimktrains2 8y ago
  I've never updated a repo with a make file and I needed to script things that didn't belong in the main make file. I'm not sure what I'd prefer to do.

masukomi 8y ago

... maybe this is crazy, but why not just name the script r and do away with the alias? that way your shell can let you know "hey that's not an executable in this dir" if you ever try and run it somewhere it isn't instead of "hell i'll run that alias for you... oh "

tedmiston 8y ago
The argument I have for keeping the .sh convention is to be able to go into an arbitrary project and run `ls *.sh` to see all of my commands.
- komon 8y ago
  Ooh, sounds like an opportunity to alias `ls *.sh` to something handy to list your available commands. You could even format it pretty. I wonder if you could further play around by having your command aliases default to figuring out what sort of project you're in and either doing the nearest 'generic' method of completing that command for that type of project or perhaps even generating a skeleton file and opening up your $EDITOR to edit to fit the project you're in.