When I run:
composer require league/flysystem-aws-s3-v3 ~1.0
I get
zsh: no such user or named directory: 1.0
I'm 99% sure there is something obvious I'm missing but I'm not really proficient in these kind of things and I found this one hard to Google.
A word ~foo expands to the absolute path to the home directory of the user foo, hence ~1.0 searches for the home directory of user 1.0. If you want to avoid this interpretation, just quote the parameter: '~1.0'.
Related
I've been creating bash scripts recently, and would like to store them in my /usr/local/bin directory. When I ls this directory, I see many, what I believe to be, symlink paths. Example:
brew -> /usr/local/HomeBrew/bin/brew
I've been able to successfully create symlinks to my own scripts and stored them in my /usr/local/bin with the ln command:
ln -s /User/me/Projects/bash/my_script /usr/local/bin/my_script
and everything runs as expected.
The problem I'm encountering, is when I to try run which my_script it's not returning a nice stdout result, like it is with the other scripts. For example running which brew returns: /usr/local/bin/brew in a nice stdout format to use with other commands.
Running which my_script, will successfully detect my script but, returns
my_script: aliased to ~/Projects/bash/my_script
This makes combining with other commands more difficult.
Can anyone explain what the difference is, and how I could possibly fix this?
You must have defined an alias named my_script, which is shadowing your symbolic link. You can do a
type -a my_script
to find all definitions. To bypass the alias, invoke it using
command my_script
Aside from this: Are you sure that you really want a link from /usr/local/bin into something which is below your /User/me? This does not look sane to me. Wouldn't it be better to simply put /User/me/Projects/bash into your PATH?
I've always been a little wobbly on OSX environment variables, but I figured that, so long as /usr/local/bin was in my $PATH, that everything residing in that folder would be usable as a command in the shell.
This doesn't appear to be happening. $ echo $PATH gives me:
/Users/[username]/.nvm/versions/node/v0.12.7/bin:/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
My /usr/local/bin folder contains a symlink to an application; let's call it some-application. But typing some-application in the shell yields the classic bash error:
-bash: some-application: command not found
It was a simple mistake on my part. I had created the symlink using a bad link location:
$ ln -s /some/non-existent/location/some-application /usr/local/bin/some-application
There was no error on creating this 'link'. The symlink name was the one used in the bash error, masking the fact that it couldn't find the original location, not the link.
For me, I would have either expected an error to be thrown on creation of the link, or at least for bash to detail which path couldn't be resolved. Something like this:
-bash: /some/non-existent/location/some-application: No such file or directory
Oh well. Case closed.
P.S
Any light being shed on why it behaves this way might be helpful to myself and others.
So, if I man cd, I get the manpage for bash builtins.
If I cd -?, I get the following:
cd -?
-bash: cd: -?: invalid option
cd: usage: cd [-L|[-P [-e]] [-#]] [dir]
I know what the first two options are. Then I searched for both options.
For the -e option, I found this answer on the Unix StackExchange.
For the -# option, I couldn’t find any explanation.
My system info:
OS X 10.9 (Mavericks)
bash 4.3.18 (installed with the Homebrew package manager for OS X)
However, if I run which cd, I get /usr/bin/cd. Homebrew doesn’t touch anything outside of /usr/local, so I can only assume this is the system’s cd.
But I can’t find the documentation for that option! It’s driving me crazy.
Does anyone know what -# does?
It's a new option (as of bash-4.3). The changelog contains the following description:
'cd' has a new `-#' option to browse a file's extended attributes on
systems that support O_XATTR.
(changelog)
Type help <name> or man bash to get more info on bash commands. (In the bash man page you can search for cd by typing / followed by a search string and enter. n to go to the next hit, shift+n to go backwards).
The bash man page contains the following:
On systems that support it, the -# option presents the extended
attributes associated with a file as a directory.
Check the man page for bash for an explanation. The relevant portion says:
If dir begins with a slash (/), then CDPATH is not used. The -P option causes cd to use the physical directory structure by resolving symbolic links while traversing dir and before processing instances of .. in dir (see also the -P option to the set builtin command); the -L option forces symbolic links to be followed by resolving the link after processing instances of .. in dir. If .. appears in dir, it is processed by removing the immediately previous pathname component from dir, back to a slash or the beginning of dir. If the -e option is supplied with -P, and the current working directory cannot be successfully determined after a successful directory change, cd will return an unsuccessful status. On systems that support it, the -# option presents the extended attributes associated with a file as a directory. An argument of - is converted to $OLDPWD before the directory change is attempted. If a non-empty directory name from CDPATH is used, or if - is the first argument, and the directory change is successful, the absolute pathname of the new working directory is written to the standard output.
I'm writing a bash script on Mac OS X that makes a symlink but when I try and open the symlink that I created it doesn't go anywhere and I get an error that it can't find the original.
OriginalPath="~/PathTo/bundle1.bundle"
NewPath="/OtherPath/bundle1.bundle"
sudo ln -s $OriginalPath $NewPath
I've also tried this:
sudo ln -s ${OriginalPath} ${NewPath}
ln sets the redirect to exactly what you give it, so it'll be interpreted relative to the location of the link. I'm actually not 100% sure how links will handle a ~, but I don't believe bash will expand it within quotes, and since it is a bash expansion, not a general filesystem one, I suspect the redirect will point to an actual directory named ~, which probably doesn't exist. Either figure out the relative path or expand it into an absolute path.
Assuming ${OriginalPath} already exists (and if it doesn't, hey, that's your problem):
The first thing I'd look at is to see if the tilde expansion is the problem. Change OriginalPath to the full path name (e.g., /Users/jpc/PathTo/bundle1.bundle). If that fixes the problem, then either just go with that or find out how to turn on tilde expansion in the shell or use the environment variable ${HOME} instead of tilde expansion.
Probably best not to use tilde expansion in the shell script anyway, as you might not be able to make sure that all users running the script will have it turned on.
I am a few steps before starting my first real programming project and I am preparing my machine. I noticed that my fullpath (what I get when I "echo $PATH" in the terminal) does not look like a "normal" one (as I see "usr/bin" quite a lot of times). What does it mean? How does it affect my use of the terminal? And how, if, can I change it back to the default one?
EDIT: I can change it just by typing "PATH=the_name_of_the_path" but it's not permanent, if I quit the session I am running and start terminal again, what I get is "/Applications/lejos_nxj/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin" (and that's because I changed it some months ago so I could usel lejos_nxj, for a course at university). Is it better I change it back to the "normal" again or should I stop worrying about it? How can I change it anyway, in case I had to?
$PATH is a variable specifying a set of directories where executable programs are located. It's normal to see /usr/bin there.
Basically, if you type a command on the terminal, like cat for example, it's going to look for cat in those directories. This way, you don't have to specify the full path to all your frequently used commands.
Here is an example of a "normal" path on a new OS X 10.6 install:
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin:/usr/X11/bin
If you see the same entries repeated again and again, then you probably have a mixup with your .bashrc vs. .bash_profile. You should set the PATH in the .bash_profile, not .bashrc, to avoid this.
$PATH under all *nixes is actually a list of colon-separated directories. Unless you see several times the /usr/bin entry, nothing's wrong (and even if you see it several times, it doesn't mean it's broken either).
At any rate, you should post what you get.
My path looks like this:
frak:~ seth$ echo $PATH
/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin
Yours should look pretty much the same. Each directory is separated by ':'. However, even if you do have /usr/bin more than once, it won't make any difference.
Observe:
frak:~ seth$ whereis units
/usr/bin/units
frak:~ seth$ units attoparsecs/s m/s
* 0.030856776
/ 32.407793
Add a /usr/bin again:
frak:~ seth$ PATH=$PATH:/usr/bin
frak:~ seth$ echo $PATH
/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin
And everything still works fine:
frak:~ seth$ whereis units
/usr/bin/units
frak:~ seth$ units attoparsecs/s m/s
* 0.030856776
/ 32.407793
PATH is a shell variable specifying where to find executables. For example, if you do a ftp (file transfer), the shell will look for the command ftp in those directories in your PATH variable before executing it. There's nothing wrong with that. If /usr/bin is not specified in your PATH, then everytime you need to use ftp, you need to give full path name , eg /usr/bin/ftp
Note that for a normal user, /usr/sbin should not be in PATH because those in /usr/sbin are mostly administrative commands.