You are not logged in.
So I can't alias ls to anything, which stinks because I'd like to alias it to ls -a as I find that much more useful.
When I try
$ which ls
it outputs
ls: aliased to ls --color=tty
which is strange because that's not something I've set.
I've tried
$ grep -r '^alias ls' /etc /home
without it returning what I'm looking for. I've searched through every bash and zsh source file I can find documentation for, also with no results. I even tried the recursive grep search from / and it went for about 5 minutes before it started throwing error messages left and right.
I'm new to arch, coming from debian and I was thinking maybe this is an arch specific config somwhere? Is this the same on anyone else's system?
Thanks, and let me know if there's anything I can try to find this pesky bugger.
Last edited by josephemorgan91 (2017-01-13 12:18:20)
Offline
The "^" in your grep is probably what messed things up. It doesn't account for whitespace at the beginning of the line.
Online
So I can't alias ls to anything, which stinks because I'd like to alias it to ls -a as I find that much more useful.
Why can't you make an alias? What error do you get? Searching for the source of the existing alias is a red herring since aliases can build on other aliases.
Edit: Also tell us what shell you are using.
aur S & M :: forum rules :: Community Ethos
Resources for Women, POC, LGBT*, and allies
Offline
The "^" in your grep is probably what messed things up. It doesn't account for whitespace at the beginning of the line.
Allright, appreciate the feedback. Honestly I'm not entirely familiar with what the "^" even does in that command, I gotta admit I just copied it from a post with the same problem.
Tried it again, removing the caret(?) and it didn't change the result. Still only finds the alias I've made, which despite being in my .bashrc and .zshrc, isn't loaded.
Offline
josephemorgan91 wrote:So I can't alias ls to anything, which stinks because I'd like to alias it to ls -a as I find that much more useful.
Why can't you make an alias? What error do you get? Searching for the source of the existing alias is a red herring since aliases can build on other aliases.
Edit: Also tell us what shell you are using.
I appreciate the help. I'm using zsh as my shell.
Your post gave me the idea to try the alias in .bashrc and to run ls in bash. I did so, and the alias worked as intended. As a side note, after editing and resourcing bashrc,
$ which ls
run from bash in the same session didn't show the alias, even after verifying that the alias was working correctly. Pretty sure that's unrelated, but it seemed strange to me.
To answer your questions directly, my other aliases in .zshrc work completely as intended. When I try to alias ls, however, it just doesn't work. I don't get an error message, just the typical ls behavior. My process is to edit .zshrc adding the alias, then source .zshrc from within zsh and test it by running ls. No mater what I do, ls runs as it would without an alias. Or maybe it's run as it would with only the
ls: aliased to ls --color=tty
that's being reported by
$ which ls
I can't tell for sure, I don't know what the output would look like without it.
Is it possible that zsh is sourcing something after .zshrc that's overwriting the alias I'm trying to set? This says that .zshrc is the last thing sourced in an interactive, non-login shell (which is what I'm using) but it isn't official documentation, so I'm not 100% confident that it's not omitting something.
edit: Thought it might be helpful to post the relevant section of my .zshrc
alias zconfig="vim ~/.zshrc"
alias zsource="source ~/.zshrc"
alias ls="ls -a"
alias ll="ls -la"
Last edited by josephemorgan91 (2017-01-11 11:53:40)
Offline
Would you mind posting your entire .zshrc?
Also, perhaps this:
grep -r 'alias[ \t]\+ls' ~ /etc
pacman -Qi zsh
pacman -Qkk zsh
--edit--
@Genis ↓ That would only be a workaround, and not solve the problem at hand.
Last edited by ayekat (2017-01-11 12:42:57)
Offline
If it helps you, in my .bashrc file I've defined an alias for ls -a like:
alias la='ls -a'
So it doesn't work the way yoy want what works fine
Offline
I don't use zsh, so it may be different, but you mention using `which ls` in bash and not seeing the alias. That is to be expected. `which` will not report an alias, use `type ls` for that.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Would you mind posting your entire .zshrc?
Also, perhaps this:grep -r 'alias[ \t]\+ls' ~ /etc pacman -Qi zsh pacman -Qkk zsh
--edit--
@Genis ↓ That would only be a workaround, and not solve the problem at hand.
I can post the whole thing, here it is:
# User Specified Aliases
alias zconfig="vim ~/.zshrc"
alias zsource="source ~/.zshrc"
alias ls="ls -a"
alias xclip="xclip -selection c"
# zsh
export ZSH=/home/joe/.oh-my-zsh
ZSH_THEME="robbyrussell"
COMPLETION_WAITING_DOTS="true"
plugins=(git)
source $ZSH/oh-my-zsh.sh
export EDITOR='vim'
Just so you don't have to ask, I'll include my other zsh related dotfiles
### /etc/zsh/zprofile
emulate sh -c 'source /etc/profile'
sudo /home/joe/Scripts/no_x_keyswapper
setleds -D +num
/etc/zsh/zshrc is blank
### /etc/profile/
#Set our umask
umask 022
# Set our default path
PATH="/usr/local/sbin:/usr/local/bin:/usr/bin"
export PATH
# Load profiles from /etc/profile.d
if test -d /etc/profile.d/; then
for profile in /etc/profile.d/*.sh; do
test -r "$profile" && . "$profile"
done
unset profile
fi
# Source global bash config
if test "$PS1" && test "$BASH" && test -z ${POSIXLY_CORRECT+x} && test -r /etc/bash.bashrc; then
. /etc/bash.bashrc
fi
# Termcap is outdated, old, and crusty, kill it.
unset TERMCAP
# Man is much better than us at figuring this out
unset MANPATH
I could include everything from /etc/profile.d/ but I've gone through it a few times and there doesn't seem to be anything alias related
### ~/.zprofile
typeset -U path
path=(~/bin ~/Android/Sdk/platform-tools $path[@])
That seems to be everything listed on the arch wiki entry for zsh. I don't see anything meaningful, but maybe I'm missing something.
Also, the out put you requested:
$ pacman -Qi zsh
Name : zsh
Version : 5.3.1-1
Description : A very advanced and programmable command interpreter (shell) for UNIX
Architecture : x86_64
URL : http://www.zsh.org/
Licenses : custom
Groups : None
Provides : None
Depends On : pcre libcap gdbm
Optional Deps : None
Required By : zsh-completions
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 5.38 MiB
Packager : Pierre Schmitz <pierre@archlinux.de>
Build Date : Thu 22 Dec 2016 11:27:12 AM PST
Install Date : Sun 08 Jan 2017 06:26:57 AM PST
Install Reason : Explicitly installed
Install Script : Yes
Validated By : Signature
$ pacman -Qkk zsh
backup file: zsh: /etc/zsh/zprofile (Modification time mismatch)
backup file: zsh: /etc/zsh/zprofile (Size mismatch)
zsh: 1077 total files, 0 altered files
The grep search didn't return any output.
Last edited by josephemorgan91 (2017-01-12 13:50:06)
Offline
If it helps you, in my .bashrc file I've defined an alias for ls -a like:
alias la='ls -a'
So it doesn't work the way yoy want what works fine
Definitely thinking of just giving up and doing that, but I'd like to understand what's causing the issue if I can.
Offline
# zsh export ZSH=/home/joe/.oh-my-zsh ... source $ZSH/oh-my-zsh.sh
There you have it.
Remove all that OMZ stuff and try if that alias goes away.
Then stop using OMZ entirely. It will only cause you more trouble like this in the future.
Offline
josephemorgan91 wrote:# zsh export ZSH=/home/joe/.oh-my-zsh ... source $ZSH/oh-my-zsh.sh
There you have it.
Remove all that OMZ stuff and try if that alias goes away.Then stop using OMZ entirely. It will only cause you more trouble like this in the future.
You were right, omz had it's own ls alias set somewhere. I went through all of its configuration files and couldn't find anything, but it would appear there's something I'm not seeing.
Moving the
source $ZSH/oh-my-zsh.sh
line before (instead of after) my ls alias fixed the problem.
Seems like when oh my zsh was being sourced, it was overwriting the alias I had set.
I actually use a couple of the omz plugins pretty religiously, is there a compelling reason I should remove it aside from the occasional unintended interaction? It's definitely going to be the first place I look if I get a weird problem like this in the future. It seems like if you're going to be removing because of the possibility of unintentional interactions, you'd be left with an extremely sparse system.
Offline
Moving the
source $ZSH/oh-my-zsh.sh
line before (instead of after) my ls alias fixed the problem.
No, it merely covered it up for the moment.
is there a compelling reason I should remove [oh my zsh] aside from the occasional unintended interaction?
It's 40% broken and 50% useless. The fact that you like the other 10% doesn't seem of sufficient value to me. More importantly though, it's 100% not understood by anyone who uses it. This is always a recipe for disaster.
It's definitely going to be the first place I look if I get a weird problem like this in the future.
What good do you think this will do, given the following:
I went through all of its configuration files and couldn't find anything, but it would appear there's something I'm not seeing.
If you have a problem in the future you'll again look at thing that you readily admit to not seeing any problems with even when you know it's the culprit. This will not work.
The likely reason you didn't find anything is that you grepped the files you knew about. But it's a tangled web of spaghetti code including other files from other parts of the file system. You'd need to search all of them and all the files that each of those files include, and all the files they include, etc, etc.
It seems like if you're going to be removing because of the possibility of unintentional interactions, you'd be left with an extremely sparse system.
No, you'd be left with a system you configured and understand.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
is there a compelling reason I should remove it aside from the occasional unintended interaction?
To me that is already a compelling reason. This alias issue was a rather mild annoyance, but there will likely be other weird side effects.
Another compelling reason is that you will not find much help in the ZSH community, since you'll be on your own with the OMZ-specific quirks and problems.
It seems like if you're going to be removing because of the possibility of unintentional interactions, you'd be left with an extremely sparse system.
While I agree that ZSH without any kind of configuration is not very useful, there is no need to load thousands of lines of shell script code for a smooth user experience. Calling ZSH without OMZ "sparse" seems very ignorant to me. As a comparison:
$ find ~/.local/etc/zsh ~/.local/etc/sh -type f -exec wc -l '{}' '+'
4 .local/etc/zsh/.zshenv
4 .local/etc/zsh/.zprofile
4 .local/etc/zsh/.zlogin
272 .local/etc/zsh/.zshrc
103 .local/etc/sh/login
15 .local/etc/sh/profile
28 .local/etc/sh/environment
115 .local/etc/sh/config
5 .local/etc/sh/profile.d/dotfiles.sh
5 .local/etc/sh/profile.d/utils.sh
24 .local/etc/sh/profile.d/altera.sh
5 .local/etc/sh/profile.d/epflscripts.sh
584 total
That's <600 SLOC of zsh config code that gives me auto-completion, vim-mode with a prompt that adapts to the mode I am currently in, a git prompt that tracks the current git repo plus a few others, a silly "print-distribution-logo-ascii-art-at-login" function, (almost) conforming to the XDG basedir spec (so I don't clutter my ~), etc. including comment lines. Plus the benefits of knowing every line of the configuration myself.
Last edited by ayekat (2017-01-13 13:18:36)
Offline