I’ll be jiggered if I know which category to post this in, but since I’m beginning with VMs I’m plumping for Get Started. I’m running Git Bash on a Windows 7 PC. I’ve created a shell script in my home directory which contains the following commands:
#!/bin/bash
cd ~/homestead_improved-master
bin/folderfix.sh
vagrant up
A minor irritation is that I cannot seem to run the script from the home directory by simply entering homestead.sh - but have to enter either ./homestead.sh or ~/homestead.sh.
When I’m done with Vagrant, I try vagrant halt but I get a message:
A Vagrant environment or target machine is required to run this
command. Run vagrant init to create a new Vagrant environment. Or,
get an ID of a target machine from vagrant global-status to run
this command on. A final option is to change to a directory with a
Vagrantfile and to try again.
If I run vagrant global-status to get the vagrant machine id and then vagrant halt fe31855 my VM closes down.
Can I do anything to make life easier for myself? (Being a lazy little Git - pun intended).
Just entering the name of the shell script won’t work since the shell would assume that homestead.sh is a global command. By preceding it with ./ you’re explicitly telling the shell that you want to execute a certain file in the current directory – another option would be sh homestead.sh.
Yes, you’re only cding within the script. This doesn’t change your actual working directory in the shell.
Yeah, you should be running vagrant commands from within the project folder, and not from your home directory. That could be the problem. If you run them from inside a directory that doesn’t have a vagrant file in it, it’ll be confused about what vagrant machine you’re asking to vagrant up.
For security reasons, Posix/'nix does not allow the current path to be implicitly added to $PATH/%PATH% when specifying a file path. This can be dangerous when considering executable files. PowerShell removed this behavior.
Anyway, in either case - Windows Command Shell or a 'nix-like sh shell requires a fully qualified path to an executable file. It just so happens that the default Windows Command Shell implicitly provides the current path by trying to be a 'pal and prepending %CD% to %PATH% when you specify a non rooted or non relative (positional) path. Veteran Windows programmers will fondly recall ill side effects such as DLL Hell, Preloading Attacks, and others as a result of this helpful feature.
nix-like/posix shells avoid entire classes of bugs and security vulnerabilities by requiring the client provide the full path. Additionally these shells provide ‘.’, ‘~’, and ‘$PWD’ to allow one to reference the “current path” in a slightly more explicit/verbose manner.
‘.’ in posix environments refers to the current path, which is equivalent to “$PWD”.
‘.’ in windows command shell refers to the current path, which is equivalent to “%CD%”.
Some quick poc to help illustrate the concept (not meant as an example of good bash scripting):
#!/bin/sh
# Get inode for a file "$f"
function get_inode {
local f="$1"
echo $(stat "$f" | egrep -io "(inode:) ([0-9]+)" | cut -d " " -f2)
}
# Check equality of two inodes $f1,$f2
function inodes_eq {
local f1="$1"
local f2="$2"
(( $(get_inode "$f1") == $(get_inode "$f2") ))
# Return 0 if equal, 1 otherwise
echo "$?"
}
