I install cygwin frequently enough that it would be handy to have the process automated. Specifically, I want to be able to specify ahead of time the packages that I want to install, so that I don't have to remember them at install-time. Is there any way to do this?
Yes, you can. Assuming you haven't installed Cygwin yet, bash isn't available, so you have to use a CMD script. Here's an example:
setup-x86.exe ^
--quiet-mode ^
--packages ^
aria2,^
atool,^
autoconf,^
...
xmlstarlet,^
zip
and add other packages to the list. The caret (^) character at the end of every line is the line continuation character in CMD scripts. The list of package names is comma-delimited, which is what the --packages option expects, although that's not documented.
You can run setup-x86.exe --help, or see the Cygwin FAQ, to read about the available command line options for setup.
If you name this script, say, setup.bat or setup.cmd, and put it in the same directory as setup-x86.exe, then you can run it to get a one-click install of Cygwin with all of the packages you want.
Note also that you'll have to specify the --site and --root options for a fresh install, or it will kick out of "quiet mode" and prompt the user anyway.
apt-cyg is similar to what I was looking for, although it requires a pre-existing cygwin install with a few non-default packages.
I don't know if you can script it, but I found a 'how-to' on making a custom package directory and the installer to go with it. This way, you can have all the packages you need and have the installer pre-selected.
You can find that article here.
Related
I'm learning to use GNU/Linux and I want to know how to install programs that cannot be installed with the package manager.
I downloaded the tarball with the Linux 64-bit Binaries (including one called "haxelib"), extracted it, changed directory in the terminal to their location (~/Downloads/things/haxe_20201231082044_5e33a78aa/), and used chmod to make them executable.
If I try a command such as haxelib list, then the terminal returns
haxelib: command not found
If I try ./haxelib list (the same command but with ./ at the start) instead, then the command works as expected.
Why can't I use it without the ./? Programs installed with the package manager can be used without the ./.
Edit: I should probably also ask: where should I put the files from the tarball? Should they all go together in the same place? I have a feeling that a folder named "things" in my Downloads folder is not the best place for them.
Due to a security update in my organisation, I can no longer use brew to tap into my organisation's repo to install a package. I can, however, manually download the .jar files that brew was installing.
So previously I did:
brew tap <repo>
brew install <package>
<package> # Run the package from anywhere
And I could run the package from anywhere, just by typing in terminal. Easy peasy.
Normally Brew installs in usr/local/Cellar/<package>/some/internal/structure/<package.exe>. But somewhere along the way it does something with aliases and symlinks and $PATH [which I am confused by] so that I can run the given package from /usr/local/bin, which is in my $PATH, by just typing <package> anywhere in terminal.
I am trying to recreate this behaviour. I was able to manually download the jar files and put them in a folder /usr/local/bin/<package>. And if I run java -jar /usr/local/bin/<package>/<package.exe> then everything runs fine.
How do I get it so that I can run <package> from anywhere in terminal, like with Brew? Also, just to be 100% clear, I want to choose the alias; I want to be able to type "abc" to run the jar files.
/usr/local/bin/ is likely in your PATH variable already. If you want to check, print it to the terminal with echo "$PATH". If it isn't, you can pick one of the other directories in there or add it to. If you want to add that directory to your PATH variable, you want to add this to the relevant dot file (likely ~/.bashrc):
export PATH="/usr/local/bin:$PATH"
PATH is a colon separated list of directories where your system will look for executables.
Now, you can just write a short script to run java for you. For example, if we have a jar file called foo.jar, you could make a short script that runs java with the full path of foo.jar like this:
/usr/local/bin/foo:
#!/bin/bash
java -jar '/path/to/foo.jar' "$#"
sneaky edit: Make sure you give this file executable permissions:
chmod +x /usr/local/bin/foo
Now, on the terminal, if I run foo without a full path, it will run this script.
The "$#" is just going to pass any arguments you sent to this script along into the java program.
This isn't the only option to achieve this. You mentioned aliases as well. You could write an alias to your .bashrc that does the same thing:
alias foo='java -jar "path/to/foo.jar"'
A symlink wouldn't really be the best option here. This would be okay if your jar file was not in the PATH and you wanted it there. BUT, the PATH variable is really only for files that can be executed directly. As you already know, jar files cannot.
If I had a compiled Golang program that I wanted to install such that I could run it with a bash command from anywhere on my computer, how would I do that? For example, in nodejs
npm install -g express
Installs express such that I can run the command
express myapp
and express will generate a file directory for a node application called "myapp" in whatever my current directory is. Is there an equivalent command for go? I believe now with the "go install" command you have to be in the directory that contains the executable in order to run it
Thanks in advance!
Update: If you're using Go 1.16, this answer still works, but go install has changed and is now the recommended method for installing executable packages. See Karim's answer for an explanation: https://stackoverflow.com/a/68559728/10490740
Using Go >= 1.11, if your current directory is within a module-based project, or you've set GO111MODULE=on in your environment, go get will not install packages "globally". It will add them to your project's go.mod file instead.
As of Go 1.11.1, setting GO111MODULE=off works to circumvent this behavior:
GO111MODULE=off go get github.com/usr/repo
Basically, by disabling the module feature for this single command, it will install to GOPATH as expected.
Projects not using modules can still go get normally to install binaries to $GOPATH/bin.
There's a lengthy conversation and multiple issues logged about this change in behavior branching from here: golang/go - cmd/go: go get should not add a dependency to go.mod #27643.
Starting with Go >= 1.16 the recommended way to install an executable is to use
go install package#version
For example, go install github.com/fatih/gomodifytags#latest.
Executables (main packages) are installed to the directory named by the GOBIN environment variable, which defaults to $GOPATH/bin or $HOME/go/bin if the GOPATH environment variable is not set. You need to add this directory to your PATH variable to run executables globally. In my case, I've added this line to my ~/.zshrc file. (if you are using bash, add it to the ~/.bash_profile file):
export PATH="$HOME/go/bin:$PATH"
Go team published a blog post about this change, here's the explanation quote:
We used to recommend go get -u program to install an executable, but this use caused too much confusion with the meaning of go get for adding or changing module version requirements in go.mod.
Refer to go install documentation for more details
As far as I know, there is no direct equivalent to npm install -g. The closest equivalent would not be go install, but go get. From the help page (go help get):
usage: go get [-d] [-f] [-fix] [-insecure] [-t] [-u] [build flags] [packages]
Get downloads and installs the packages named by the import paths,
along with their dependencies.
By default, go get installs binaries to $GOPATH/bin, so the easiest way to make those binaries callable from everywhere is to add that directory to your $PATH.
For this, put the following line into your .bashrc (or .zshrc, depending on which shell you're using):
export PATH="$PATH:$GOPATH/bin"
Alternatively, you could also copy or link the executables to /usr/local/bin:
ln -s $GOPATH/bin/some-binary /usr/local/bin/some-binary
Short solution for Linux users:
Use the go get command as usual
Add the following lines to .bashrc:
# This is the default GOPATH, you should confirm with the 'go env' command
export GOPATH=$HOME/go
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin
Restart terminal or source it. Installed binaries will be available globally.
For Go v1.8+
go install package_name#latest
Caveat: this answer is outdated following the 2020 deprecation of go get. The solution presented here won't work with newer Go runtime installs.
The closest analogue of this in Go would be go get. By default, it will fetch a Go package from a supplied repository URL, and requires a $GOPATH variable to be set in your shell so that Go knows where to store the packages (and subsequently where to find them when compiling code depending on go get-ted packages).
Example syntax:
$ go get github.com/user/repo
The behaviour supplied by npm's -g flag is default, and packages installed using go get are normally available globally.
See go get --help for more information about the command.
As mentioned by #helmbert, adding your $GOPATH to your $PATH is useful if you're installing standalone packages.
if you are using zsh :
first: install your package using :
go install package#version
then , you edit your .zshrc file
nano ~/.zshrc
Add this line to the end of .zshrc file :
export PATH="$HOME/go/bin:$PATH"
last but not least :
source ~/.zshrc
then open a new terminal and execute your command :)
TL;DR at the bottom. I'm going to walk you through how I came to this conclusion, and why the more obvious solutions don't work.
Upon seeing this question, I thought "If I could set root's GOPATH=/usr, it would install things in /usr/bin/ and /usr/src!"
So I tried the obvious thing:
Add GOPATH=/usr to root's .bashrc.
And it worked!
Sort of.
Not really.
Turns out, sudo doesn't execute root's .bashrc. For "security" or something like that.
Do env_set or something in /etc/sudoers
Turns out, /etc/sudoers can only remove environment variables. There's no env_set directive.
(As far as I can find)
Dig through man sudoers.
Where does sudo get it's default set of environment variables from?
Well, the first one in the list is /etc/environment, so that's the one I used.
sudo echo "GOPATH=/usr" >> /etc/environment
sudo go get <repo>
Binaries will be put in /usr/bin, and sources will be put in /usr/src.
Running go as non-root will use GOPATH the "normal" way.
If you don't have go installed, you may use the gobinaries. it builds an on-demand binary of the project from github repo.
The command to install the go package would be:
curl -sf https://gobinaries.com/rakyll/hey | sh
Ultimate Goal:
I'm trying to convert a binary plist file to an xml format so that I can put it in an array and grab values from it. What I'm finding via web search on this is that the command for Linux comes from libplist.
Problem: I ran "yum install libplist" and it told me libplist is already installed and latest version. I've read that if I enter the following command:
plutil -i /mypath/file.plist > /mypath/file.xml.plist
That this will help accomplish my ultimate goal. However, when I do this only a blank file called file.xml.plist is created. Further, with this command and any other command involving plutil, I get a "bash: plutil: command not found. . ." error. Is libplist seemingly not installed (even though it says it is) or why would I repeatedly get this error? Thanks for your help.
You can use yum to look for a package knowing the binary you want. For instance, if I want to install the package that provides plutil, I simply run this command:
$> yum provides plutil
Unfortunately, the result is No matches found... But you say you read that the libplist package provides this tool. Maybe it was renamed ? Let's use repoquery for this (if you don't have it, yum provides repoquery tells you that you need to install yum-utils).
$> repoquery --list libplist
/usr/bin/plistutil
/usr/lib/libplist++.so.3
/usr/lib/libplist++.so.3.0.0
/usr/lib/libplist.so.3
/usr/lib/libplist.so.3.0.0
/usr/share/doc/libplist
/usr/share/doc/libplist/AUTHORS
/usr/share/doc/libplist/COPYING.LESSER
/usr/share/doc/libplist/README
And what I see is that a program called plistutil was installed with this package !
I've never used plutil, so I can't tell you for sure plistutil is the program you want (but it probably is). What I wanted to do instead with this post is to show how you can use yum to install the packages you need !
I ran across this thread while Googling for the same thing myself. After looking at a few solutions for my own company (Screenplay) I decided to fork and iterate on a open-source, cross-platform, drop-in replacement for plutil:
https://github.com/screenplaydev/plutil
It's forked from Facebook's xcbuild (a tool developed by them to build xcode projects on Linux), but stripped down to just provide plist-editting functionality. That way you won't need to maintain separate code-paths for Mac and Linux environments.
Hope that's helpful!
I was wondering if the following is possible.
I have a BASH script that I want to make available for some people but I wanted them to only have to "install" the program and not messing around with terminal, so I thought a .deb would be cool.
So what would the "install" do?
Simple. I want to move the script and an icon to a folder (any folder, but I was wondering some hidden folder in Home) and then run a script that creates a launcher in the Applications menu for the first script. It seems there isn't much to it, but for what I've searched, there doesn't seem to be a lot of info...
How can I accomplish this?
By the way, I'm using Ubuntu 11.04.
Basically (install and) run dh-make to set up the debian/ directory, edit the generated files (mainly remove the many you do not need, and fill in a package description and any dependencies in debian/control), then debuild-us -uc -b.
You may also have to set up a simple Makefile for debian/rules to call; it probably only needs an install target to copy the binary to $(DESTDIR)/usr/bin.
Binaries install into /usr/bin and you should not try to override that. The way to have a menu is to add a .desktop file.
Once you have a good .deb you will need to set up a repo for distributing it. The simplest solution is probably to set up a launchpad.net account and create a personal PPA there.
It's not hard to find more information on these topics, but of course, you need to know what to look for. The canonical documentation is the Debian New Maintainer's Guide.
Found this video on youtube that explains IN FULL the process of creating a *.deb for a script or program and even mentions how to do it for a C program.
Full guide in how to build simple *.deb package
Has one bug, btw, that the author, during the making of the *.deb, didn't notice. The path in the *.desktop file for the EXEC parameter is wrong in the example.