I'm migrating from Ubuntu to MacOS with my MacBook Pro (M2). I'm using ohmyzsh with the docker and docker-compose plugin. Docker has been installed with [Docker Desktop setup](https://docs.docker.com/desktop/install/mac-install/) . All works fine except the autocompletion for the container names. If I type docker start and ⮕Tab it just shows me the files of my current directory, but not the list of available containers. I'm expecting the autosuggestion to work here and show me a list of all containers which could be started. This worked fine within Ubuntu. I'd rather not run docker virtually or have to shell in to an already running container to get this functionality. Is there a trick which I could use so the macOS command line has more completion options with zsh and docker for Mac?

Hey Guys I'm using zsh and moved my .zshrc,.zsh_history and .oh-my-zsh to the dropbox folder to back up them and use them everywhere, and I created a Symbolic Link to them to use them but every time I create a Symbolic Link for.zsh_history I see that has been created but every time that I open the terminal and check home directory I see that .zsh_history file has no Symbolic Link. and I use this command: mv .zsh_history ~/Dropbox/ZSH_Backup/ && rm -f .zsh_history && ln -s ~/Dropbox/ZSH_Backup/.zsh_history ~ So what is the problem?

I installed https://git.zx2c4.com/password-store/tree/src/completion/pass.zsh-completion under /opt/homebrew/share/zsh-completions/pass.zsh-completion and enabled compinit in ~/.zshrc:

# define zsh-completion
if type brew &>/dev/null; then
    FPATH=$(brew --prefix)/share/zsh-completions:$FPATH

    autoload -Uz compinit
    compinit
fi

And the pass completion works, but only with top level word. For example I have misc/keycard. When I type pass show m[TAB], I can see misc prompted. But when I type pass show k[TAB], misc/keycard is not showing. Please instruct how to modify this completion file to enable partial regex match. Basically it's impractical to use right now; as I put passwords into dir to ease my memory; I will not remember the whole structure of dir tree.

I am a Unix user and have been using zsh for more than 20 years. I have been using zsh as my login shell for many years on macOS High Sierra. I use only ~/.zprofile and for sharing what is relevant to be common, with /bin/sh and /bin/bash it calls explicitely ~/.profile. I don't use any other shell initialization file outside of: ~/.zprofile ~/.profile Recently I made the switch to Big Sur. And I discovered a problem which didn't occur before and which doesn't occur on any Unix I work on: inside Terminal and xterm my ~/.zprofile is not correctly read. Since I didn't pass on Catalina ( too many problems ) I cannot verify if the problem started with Catalina or Big Sur. If I load it explicitely: . ~/.zprofile it is read without any error. Most notably I see it at the setting of PS1 which is the correct one I see on all other systems I am working on. I didn't modify either /etc/zprofile or /etc/zshrc. Here are my very basics shell initialization files: --- # ~/.zprofile #! /bin/zsh . ${HOME}/.profile PS1="### %B%T %m%b:%32<...<%/ %# " export PS1 PS2="# " export PS2 HISTFILE=~/.zsh_history export HISTFILE HISTSIZE=1024 export HISTSIZE VISUAL=vi export VISUAL tty -s && stty -istrip --- # ~/.profile #!/bin/sh CDPATH=.:~/Links export CDPATH PATH=/opt/local/bin:/opt/local/sbin:/bin:/usr/bin:/sbin:/usr/sbin:/opt/X11/bin:/opt/bin export PATH MANPATH=/opt/local/share/man:/usr/share/man:/opt/X11/share/man:/opt/man export MANPATH LANG=en_US.UTF-8 export LANG BC_ENV_ARGS="${HOME}/.bcrc" export BC_ENV_ARGS

My macOS 14.2.1 (Darwin 23.2.0) is arm64 by default. I set up a bunch of x86_64 versions for different apps (have Rosetta 2 set up as well). For example, cmake and Homebrew. But when I call them with arch -x86_64 prefix, the OS cannot find them:

arch -x86_64 cmake
arch: posix_spawnp: cmake: Bad CPU type in executable

The following thing works though:

arch -x86_64 /usr/local/Homebrew/Cellar/cmake/3.31.4/bin/cmake

The same is with the other apps installed for x86_64. Even when I call arch -x86_64 zsh and switch my bash to the x86_64 mode, it can't find the paths. When I call

which cmake

It always shows only one path (arm64), either when I'm on arm64 or x86_64 version of zsh:

/opt/homebrew/bin/cmake

Should I manually add all paths to the x86_64 applications to $PATH or is there a better way to tell the OS to do this automatically?

**Problem** On my new M3 Mac Pro (36 GB RAM) running macOS Sequoia 15.3.2, launching a new interactive shell in both the built‑in Terminal.app and the GPU‑accelerated Ghostty takes orders of magnitude longer than on my Linux/Windows boxes. I frequently use tmux, and spawning new panes can take > 1 second, whereas on Linux/Windows it’s real 0.15; user 0.04; sys 0.03
real 0.13; user 0.03; sys 0.03
real 0.14; user 0.03; sys 0.03
**With plugins enabled:** 3. compinit tweaks & zprof analysis - Precompiled cache, removed old dump files, no significant improvement. 4. Homebrew & some cli tools also feel sluggish, suggesting a deeper system issue. **Environment** - macOS: Sequoia 15.3.2 - Hardware: Apple M3 Pro, 36 GB RAM - Shells tested: - /bin/zsh (default) - /bin/bash - Measurement tool: /usr/bin/time and zprof **Questions** Has anyone observed 1-2 second cold startup on an M3 Mac for Zsh, even with minimal config?
Are there known system-wide factors (e.g. Rosetta layers, filesystem checks, notarization delays) that could slow down every new shell instance?
How can I diagnose what’s happening during that 1 second (e.g. tracing dynamic libraries, file-system stalls)?
Any tweaks or workarounds to get terminal/spawn times closer to < 0.1 s? Thanks in advance for any insights! EDIT: After using zcomet instead of zinit and p10k instead of starship. I think the issue is mostly connected to cold start vs. warm start of the terminal. If everything is cached, the startup time is in the ball park of 5ms which is fine. But the cold start of the terminal after the recent os update is 2-6 seconds and really annoying. I also thought about a stupid way of just opening a terminal in the background with a cron job, but the terminal isn't a tty and therefore not useful. Any ideas how I can reduce the cold start time or keep the terminal also "warm"?

I recently updated my Ventura OS to 13.7.5 (from 13.7.4.?). I am now getting this mysterious error message whenever I try to run a script that is written in bash:

# NOTE: the pwd is the same folder that "anyscript.sh" is located in 

% ./anyscript.sh
zsh: operation not permitted: ./anyscript.sh

##### FWIW: >I use a current version of bash that I installed from "MacPorts": GNU bash, version 5.2.37(1)-release (aarch64-apple-darwin22.6.0) I get the same error if I try the "full path"; i.e.:

% /Users/seamus/scripts/anyscript.sh
zsh: operation not permitted: /Users/jmoore/scripts/rsync_pswdsafe/pwsafe_bkup.sh

I just viewed the "update log" for 13.7.5, and it seems Apple's motivation for this unusual late-term update is "security issues". Nothing I saw in [Apple's update log](https://support.apple.com/en-us/122375) suggested an association with this issue, but: * it's happened since the update * Apple has a record of breaking things during updates! Has anyone else had similar issues - or have a clue as to what this update might have wrought - or how to roll back the update - or have a cogent theory on how to fix the problem?

Every time I open a new Terminal window or tab, it shows this error before the shell prompt:

/etc/zshrc_Apple_Terminal:14: INSIDE_EMACS: parameter not set

(I don't use emacs, and I've noticed no other ill effects.) As that indicates, my default shell is zsh.  The error also appears when starting a new zsh instance from within any existing shell. Line 14 of /etc/zshrc_Apple_Terminal is:

if [ -z "$INSIDE_EMACS" ]; then

So that file clearly expects $INSIDE_EMACS to be set, and gives the error when it's not.  But I've not been able to find out what should be setting it (that's clearly not working on my machine).  I have various user-level shell startup files, but none of those seem to be the cause, as that message appears before any of them have run. There's an obvious workaround: edit that file (as root) and e.g. replace $INSIDE_EMACS with ${INSIDE_EMACS-} (which silently expands to empty string if the variable's not set).  That works fine — but every time I upgrade macOS, that file gets replaced and the error is back!  (This has happened with every upgrade since around macOS 12 Monterey; I'm now on the current macOS 15.5.) I've not found this error online (other than my own mention in [this answer](https://apple.stackexchange.com/a/439072/291214)) , so I'm guessing it's not common, and probably triggered by some quirk of my own set-up.  But I haven't found any possible cause. What can I do to make this error go away for good?  What _should_ be setting $INSIDE_EMACS?

It seems a recent macOS X upgrade changed previous behavior in Terminal. (I'm currently on Sequoia 15.4.1) I'm used to having different windows opened with different settings (that can be defined in Terminal preferences). I use them to do different things, for example, one for default commands, one for man consultation, etc. Normally, Apple should keep a different history for each window. This is now broken. If I quit the app, the recent window history is lost when I reopen, and I have a common partial history. Specifically : - I start 3 windows with different colors, fonts and font size, size, and default directory - Each has zsh shell (standard Terminal behavior) - I don't close them except when quitting terminal. - If I restart each window has lost its previous shell history Hints for remedy ~/.zsh_sessions is a directory that stores each history session, but it seems the /etc/zshrc_Apple_Terminal file that should organize it has a bug. One hint is that a dedicated .history file per window is not created when one quits the app (only when a window is closed) It should be possible to add some lines to ~/.zshrc to force the right history to be created and reloaded. I wonder if anyone has already done the job?

On macOS, there is a sessions directory that combines commands from multiple zsh sessions into a single history file. Is it necessary to use [tag:zsh] *shell options* in the .zshrc file, to manipulate how zsh handles history, so that commands are appended to .zsh_history, or are these options redundant and ignored? I see many people recommend, when transitioning from bash to zsh, to add the following options to make history include commands from other sessions and add other functionality (that appears to be built in):

APPEND_HISTORY
HISTFILE=~/.zsh_history
HISTSIZE=100000000
SAVEHIST=100000000
setopt INC_APPEND_HISTORY
[...]

However, it seems those are built in and needn't be specified. Bonus question: Can one list multiple shell options after a single setopt, instead of having each option in a separate setopt statement?

I recently discovered that launchd on macOS provides an initial, default $PATH to new terminal windows that is not the default path set by macOS at log in, but instead is produced by launchd according to (presumably) its own internal logic — *without* changes ever having been made via either launchctl or any .plist file that I could find. This is the case whether using the Terminal.app distributed by Apple, or a third-party terminal such as Alacritty.app. The default path on macOS at log in, as can be verified with sysctl -n user.cs_path, is

/usr/bin:/bin:/usr/sbin:/sbin

But when I placed echo $PATH on the first line of ~/.zshenv, which is sourced *before* /etc/zprofile and any other shell configuration file, I was seeing an entirely different $PATH when opening a new window in Alacritty:

/usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin

Which I verified to be coming from launchd by searching the output of launchctl dumpstate:

pid/72911 = {
	type = pid
	originator = /Applications/Alacritty.app
	creator = alacritty
	...
	environment = {
		PATH => /usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin
		...
	}
        ...
}

After restarting Alacritty, with only one window and one instance of the shell the same echo command produced:

/usr/bin:/bin:/usr/sbin:/sbin

Which is what it should be. But then, opening the default Terminal.app, I get

/usr/bin:/bin

Which is, again, not the OS default. This doesn’t necessarily affect my ability to use the shell because I can set $PATH in .zshenv or .zprofile to whatever I’d like, but it does require that I override the $PATH that launchd sets if I wish to control search order. In fact, what launchd is doing makes controlling search order crucial because there is apparently no guarantee that the initial $PATH handed to the shell will be consistent. Does anybody know why launchd is providing an inconsistent $PATH? Is there any rhyme or reason to what it decides to include or not include in the $PATH that it provides to every shell created with every new terminal window, and varying it by terminal application? Again, I have *never* 1. issued launchctl setenv PATH 2. issued either sudo launchctl config user or config system 3. modified any .plist file anywhere (or found any that set the PathEnvironmentVariable key). I am running macOS Sequoia 15.4 (24E248) on an M2 MacBook Pro, using the stock Zsh shell. The closest answer I could find mentions that launchd manipulates the default $PATH, but the author doesn’t specify how or why. --- ### Update 1 ### For the stock Terminal app, launchctl dumpstate is showing

pid/45557 = {
	type = pid
	originator = /System/Applications/Utilities/Terminal.app
	creator = Terminal
        ...
	environment = {
		PATH => /usr/bin:/bin:/usr/sbin:/sbin
                ...
        }
        ...
}

Which is indeed the correct, default $PATH. However, for the stock Terminal app, an echo $PATH statement on the first line of .zshenv continues to result in the truncated

/usr/bin:/bin

--- ### Update 2 ### The developers working on Alacritty [have told me](https://github.com/alacritty/alacritty/issues/8535) that they *do not touch* the $PATH variable. --- ### Update 3 ### With echo $PATH as the first line in .zshenv producing

/usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin

in Alacritty, and

/usr/bin:/bin

in Terminal, subsequently executing

/usr/bin/env -i /bin/zsh -l -osourcetrace

per [Gairfowl](https://apple.stackexchange.com/users/274760/gairfowl)’s suggestion (see comments) shows that same echo command outputting a completely different $PATH in both Alacritty and Terminal:

+/Users/Me/.zshenv:1>       # line 1
/bin:/usr/bin:/usr/ucb:/usr/local/bin    # line 2 echo $PATH

There is no /usr/ucb directory or file, hidden or not, that I could find. But given that a Google search for “ucb” tells me it is a reference to "University of California, Berkeley" (and that the output is from env -i zsh), could it be Zsh itself is manipulating the initial $PATH? And then either it or something else in macOS is inconsistently transforming /usr/ucb into one of these not-configured paths before completing echo $PATH on the first line of .zshenv, and *sometimes* informing launchd of the change (causing it to appear in the launchctl dumpstate output)? Note that those two lines from the env output are printed *before* /etc/zprofile is sourced, thus Apple's path_helper utility is not yet in play. --- I should point out that in all my examples thus far the shell has been consistently in both login and interactive states, verified with setopt. --- ### Update 4 ### The developers working on Alacritty generously pointed me to [the section of their source code](https://github.com/chrisnc/alacritty/blob/6566dd3defa9f080dabb295740dc1dac06e3b8fb/alacritty_terminal/src/tty/unix.rs#L131-L150) responsible for launching new shells (lines 131 through 150). What it shows is, essentially (when zsh is the default shell),

/usr/bin/login -flp "$USER" /bin/zsh "-c exec -a -zsh /bin/zsh"

To paraphrase all the man pages, login -p will enter a $PATH into the new shell environment that it gets from pam(3) via environ(7) and execve(2). The man page for environ(7) explains that login(1), when -p is absent, sets the $PATH to:

/usr/bin:/bin

Which may explain what I’m seeing in Terminal.app (the source code for which I probably can’t peruse). But this doesn’t account for what echo $PATH is printing when in Alacritty, where login -p is being called:

/usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin

Or what /usr/bin/env -i /bin/zsh -l -osourcetrace outputs in both Alacritty and Terminal:

/bin:/usr/bin:/usr/ucb:/usr/local/bin

At this point my only guess is that pam_launchd.so (listed in /etc/pam.d/login) is where the uncertain and inconsistent initial $PATH, as printed by echo $PATH when in Alacritty, is coming from. But I don't know. And I certainly don't know why. As for the odd (albeit consistent) /usr/bin/env -i /bin/zsh -l -osourcetrace output including /usr/ucb — a very old default leaking out of but ultimately overridden by Zsh? --- ### Point of clarification ### The example I’ve given of the path output by echo $PATH at the top of .zshenv when in Alacritty (thus acquired via login -p),

/usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin:/usr/sbin:/sbin

is an **example**. It’s **not** consistent. Sometimes it is that path, sometimes it is

/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

and occassionally it is

/usr/bin:/bin:/usr/sbin:/sbin

What I would like to know is what it will be tomorrow, why, and whether I can lock it down without overriding it.

I've recently switched from Hyper terminal (no longer maintained) to iterm2. I'm surprised that iterm2 seems to be using vi mode: instead of going to start and end of line when I press ctrl+a/ctrl+e it emits literal ^A and ^E. I don't remember ever configuring vi mode on purpose. iterm2's configuration GUI overwhelms me. I've tested running zsh in factory mode (zsh -f), and even there iterm2 uses vi mode. In contrast, when I use Hyper or the inbuilt terminal, zsh is in default readline mode. How can I fix this? I've gone through iterm2 documentation and issue tracker and couldn't find anything. Interestingly, when I run zsh -f in inbuilt Terminal, it _is_ in vi mode. Similar question over at superuser, which has been open for 10 years without answer: https://superuser.com/questions/840134/unintentional-vi-mode-in-iterm-on-mac

This question may already be answered on here somewhere, but I'm unsure what keywords to use for my search. In the Terminal, I frequently navigate around lines using the meta+left or meta+right arrow keys. In most places I do this — emacs, ssh'd into remote computers running bash, even typing in this box — meta+right *doesn't* jump past spaces to the start of the next word. But in the Terminal, running on my macbook, it does. Also, on my computer, these two commands jump past special characters such as *~/!'\".. How can I change this behavior? Or find these settings in a remote computer's bash, and the corresponding ones in my zsh, to help me move them over? Concrete examples of current vs preferred behavior: foo bar 1234567 ↑ cursor at position (1); meta+right arrow; cursor at position 5. I'd prefer the cursor end up at position 4. foo*/ bar 123456789 ↑ cursor at position (1); meta+right arrow; cursor at position 7. I'd prefer the cursor end up at position 4. (My preferred behavior would make another meta+right then jump to position 10, no matter how many special characters are in the */ character block. Meta+left would jump from e.g. position 9 to position 8, then position 1.) I'm running macOS 15.3.1, and using Terminal version 2.14 with zsh.

I have been using iterm2 and I created an applescript to automate the process of opening some tabs I need to work in my project. I opens a few tabs, moves to directories, run a few statements (git pull, npm install, etc..) and set the session name (tab name). See the example:

#!/usr/bin/osascript
tell application "iTerm2"

  tell current window
    create tab with default profile
    set backendTab to current session
  end tell

  tell backendTab
    write text "cd /Users/felipe/projects/backend && git pull && npm install"
    write text "clear"
    set name to "backend"
  end tell
end tell

And I call it from a function in my ~/.zshrc

function dev() {
  osascript dev.scpt
}

It works, but the problem is when I run any command in these tabs such as npm start to run my app, it changes the tab name. If I right click on the tab, I can see the session name set, and a unlocked icon next to it: If I click on it, it switches to locked, which provides the behaviour I want, by prefixing the session name in the tab title. **Question**: How can I set this lock via applescript? Thank you!

I looks like my iterms terminal is sourcing bash before using zsh and it is doing it multiple times. I can't figure out why. On the left is the startup from my mac terminal and on the right from items I have 1 profile on items that runs zsh Does anyone know why this could happen? Here is my system info: macos: 14.6.1 iterms: 3.5.4 zsh: 5.9 omz: master (c68ff8ae)

Does anyone know what the escape sequences are to show "working directory" and "document" in Mac OSX Terminal.app? I'm trying the method to urlencode a URL and it's not working with zsh. I have a graphic of the dialog in Preferences below. So far, I've only been able to get the following working which allows a drop down to the current path on the left of the top bar: _PWD=$(echo $PWD| sed "s;$HOME;~;") __SHELL="zsh" printf "\033]0;$USER@$HOSTNAME '${_PWD}' ${__SHELL}\007" I'm not sure why above works, however if I remove the escape code the drop down isn't displayed anymore. I tried the following per the directions to percent "urlencode" a URL to a file, but it's not working: PWD_URL="$(urlencode file:$PWD)" printf "\033]6;%s\007" ${PWD_URL} printf "\033]7;%s\007" ${PWD_URL} urlencode () { string=$1 while [ -n "$string" ]; do tail=${string#?} head=${string%$tail} case $head in [-._~0-9A-Za-z]) printf %c "$head";; *) printf %%%02x "'$head" esac string=$tail done echo } I have "Working directory or document" and "Path" enabled above escape sequences. ref: my copyright fair use Here's an example of output from "urlencode" I'm passing in the escape sequence: \033]7;file%3a%2f%2flocalhost%2f%2fUsers%2fusername\007

I try run my Sublime Text 4 in terminal. And I am using MacOS. However, I see after I run the command of sublime_text, it does not return until I manually turn off the Sublime Text. This is my commands: % alias subl="/Users/yaohuazhuo/Desktop/Self\ Installed\ Applications/Sublime\ Text.app/Contents/MacOS/sublime_text -w" % subl 2025-01-30 16:54:33.108 sublime_text[14540:707456] +[IMKClient subclass]: chose IMKClient_Modern So I tried different options, including removing the "-w". And I have even tried the "nohup" from this post: https://superuser.com/questions/178587/how-do-i-detach-a-process-from-terminal-entirely But it still shows "appending output to nohup.out" and the command line is still not returned So how can I make the command return/detach from terminal after the sublime_text is opened?

I'm trying to create this alias: alias mrc="php artisan make:controller $(user_input) --resource" so that I can just type mrc ControllerName in the terminal to produce: php artisan make:controller ControllerName --resource Is there a way to do that?

We have added custom modifications to the /etc/zshrc, which work. The issue is following an OS update (for example recently went from 13.2 to 13.3), the file gets overwritten and we lose our modifications. Does anyone know whether there is any other zsh related file in /etc that is safe from update related overwrites? We are eyeing /etc/zprofile as a possibility, but not sure if that is any less at risk? Does Apple provide any guidance here for system administrators?

I use iTerm2 apps as my terminal option on my Mac computers. On my 1st Mac, when I type clear, it just clears out the current screen, and when I scroll up, it could still show the previous contents on this tab which I really like. On my 2nd Mac, however, when I type clear, it clears everything out of this tab. When I try to scroll up, there's nothing’s present. How can I make my 2nd Mac behave the same as my 1st one? I've checked every single configuration in between these two machines for iTerm and they look identical, both are using oh-my-zsh.