I'm made a package that is meant to be installed globally and run via the command line. n is an example of a package that does this, though it isn't an actual nodejs script, but a bash script. I was considering aliases but that limits my support to the os's whose various aliasing methods I implement. Is there a better, more universal way to do that that I am missing, or am I forced to insert alias-generating functions for each supported system?
Related
I'm trying to write scripts that allow me to switch my development environment.
I want to write a script so that I can call it like this:
switchdevA
and inside that script, one of the things it should do is switch to node v16.16.0
inside switchdevA i have the following:
#!/bin/zsh
source ~/.zshrc
nvm use v16.16.0
the output says that I have switched to node v16.16.0, but when I type node -v I get:
v12.22.12
I can fix if i call source switchdevA, but should I do it that way? Other things like java don't seem to require me sourcing. In addition, the installation is lost if I start a new zsh session, ideally it should install for the current session and all future sessions.
What's the best practice around this?
A quick clarification: NVM is a shell function and not an executable.
You've correctly identified that source switchdevA will work properly, and that it is different from other version managers.
One solution is to keep your script as is, and create an additional shell alias that will run source scriptname (e.g. alias switchdevA='source switchdevA').
Unfortunately, for your other request to keep the current Node version in all future shell sessions, that can’t be achieved unless you have some persistence added in. For example, a simple file named ~/.lastnode. Then, in your ~/.zshrc, you would have a line nvm use "$(cat ~/.lastnode)" (which comes after the initialization of NVM). Finally, the original script would need to include a line at the bottom to update the last selected Node version: nvm version > ~/.lastnode.
I am familiar with how to create application commands from this doc. I wonder if there is a way to configure site-wide commands that would fetch a particular application and change the CWD to the cloned application. Or would this be more in the rake solution space?
thx
I don't think anything really belongs in the rake solution space.
Origen does support the concept of creating a plugin which adds global commands - http://origen-sdk.org/origen/guides/plugins/creating/#Sharing_Global_Commands
The procedure is to create a regular Origen plugin, and then configure it with a global command launcher as in this example - https://github.com/Origen-SDK/origen_sim/blob/master/config/application.rb#L32
Then gem install my_plugin to your global Ruby environment. Then, anywhere in your environment, including outside of application workspaces, you will be able to run origen my_plugin_command.
I'm building a command line tool using node/javascript, and want to make it available as an npm module. The tool requires a wrapping shell / windows batch script, but how do I install different scripts for different platforms? In package.json I have
"bin" : {
"lookup-bat" : "./bin/lookup.bat",
"lookup-sh" : "./bin/lookup.sh"
}
but I would like to have the same command name, regardless of platform. Is this possible?
Usually you don t mind about that.
Usually, ./bin/lookup is a js file starting with the appropriate shebang #!/usr/bin/env node.
NPM does the rest.
If the program behavior needs to be different for the runtime OS, you shall implement a sort of if(process.platform.match(/win/)) within your program.
I’ve written a very small application in Go, and configured an AWS Linux AMI to host. The application is a very simple web server. I’ve installed Go on the Linux VM by following the instructions in the official documentation to the letter. My application runs as expected when invoked with the “go run main.go” command.
However, I receive an “Invalid argument” error when I attempt to manually launch the binary file generated as a result of running “go install”. Instead, if I run “go build” (which I understand to be essentially the same thing, with a few exceptions) and then invoke the resulting binary, the application launches as expected.
I’m invoking the file from within the $GOPATH/bin/ folder as follows:
./myapp
I’ve also added $GOPATH/bin to the $PATH variable.
I have also moved the binary from $GOPATH/bin/ to the src folder, and successfully run it from there.
The Linux instance is a 64-bit instance, and I have installed the corresponding Go 64-bit installation.
go build builds everything (that is, all dependent packages), then produces the resulting executable files and then discards the intermediate results (see this for an alternative take; also consider carefully reading outputs of go help build and go help install).
go install, on the contrary, uses precompiled versions of the dependent packages, if it finds them; otherwise it builds them as well, and installs under $PATH/pkg. Hence I might suggest that go install sees some outdated packages which screw the resulting build.
Consider running go install ./... in your $GOPATH/src.
Or may be just selective go install uri/of/the/package for each dependent package, and then retry building the executable.
One of the things I still can't wrap my head around is rules of thumb to uninstall programs in *nix environments. Most of the time I'm happy to let the sleeping dogs lie and not uninstall software that I no longer need. But from time to time I end up with several Apaches, svn, etc.
So far here's what I know about dealing with this:
1) if you installed using apt-get or yum, there's an uninstall command. Very rarely there's an uninstall script somewhere in the app's folder, something like uninstall.sh
2) to figure out which particular install is being called from the command line use "type -a" command
3) use "sudo find / | grep" to find where else stuff might be installed (from what I understand type only looks for things that are in the PATH variable)
4) Add/change order of things in PATH to make the desireable version of the app to be first in line or add an alias to .bashrc
5) delete the stuff I no longer want. This one is easy if the application was installed only in one folder, but tricky if there are multiple. One trick that I've heard of is running a find with a time range to find all the files that changed arount the time when the install happened - that roughly shows what was changed and added.
Do you have anything to add/correct?
If you didn't use a package manager (rpm, apt, etc), then you probably installed from source. To install, you performed a process along the lines of ./configure && make && make install. If the application is well-behaved, that "install" make target should be coupled with an "uninstall" target. So extract the sources again, configure again (with the same paths), and make uninstall.
Generally, if you're compiling something from source, the procedure will be
$ make
$ su
# make install
in which case, the vast majority of programs will have an uninstall target, which will let you reverse the steps that happened during install by
$ su
# make uninstall
As always, read the program's README or INSTALL files to determine what's available. In most situations you'll either install something via a package manager (which will also handle the uninstall), or you'll have invoked some kind of manual process (which should have come with a readme explaining how to uninstall it).