Odd Terminal Results?

So it’s been a long while since I delved into Terminal… but I had to try it. I got this yesterday and each time I launched it today, this always shows up:

Last login: Fri Feb 28 12:30:47 on ttys000

The application /Applications/Preview.app cannot be opened for an unexpected reason, error=Error Domain=NSCocoaErrorDomain Code=260 “The file “Preview.app” couldn’t be opened because there is no such file.” UserInfo={NSURL=file:///Applications/Preview.app/, NSFilePath=/Applications/Preview.app, NSUnderlyingError=0x6000032f4a20 {Error Domain=NSPOSIXErrorDomain Code=2 “No such file or directory”}}

[Pauls-Mac-mini:~] paulcons%

Uh, Preview (11.0) opens and runs just fine. Oddly enough, it’s GetInfo shows 2/4/25 as both the created and modified so I assume it was this version got updated? Huh, I have not gotten any requests for updating… does macOS do silent, auto updates to their apps?

How can I get rid of this? Can I stop it from always appearing?

The Preview application is no longer in the /Applications directory. It is in /System/Applications, part of the macOS signed-system volume (SSV).

You have something (I don’t know what) configured to launch /Applications/Preview.app whenever you open a Terminal window. It is failing because the app is now /System/Applications/Preview.app.

I assume this launch-command was added to your system when you were running macOS 10.15 (Catalina) or earlier (11, “Big Sur” introduced the SSV).

As for how to remove this configuration, that will depend on where it is and what application put it there. I would start to see if you have a file in your home directory named .profile, .bashrc or .zshrc. The shell (run by Terminal whenever you open a new window) will run one of these at startup in order to install any preferences you may have configured for use in those terminal sessions.

If you see something in there that looks like open /Applications/Preview.app, well, that would do it. If not, then the culprit will lie elsewhere.

4 Likes

Ahhhh. I was just going to ask questions about finding all those apps on that locations in addition to the ones is /Applications. Those app DO show up there and do not look like any kind of symlink.

Trust me I never did anything of the sort. BUT I DO remember that when I used to launch BBEdit (High Sierra days) Preview also got launched. I had a email conversation with Rich Siegel who had no idea why or how to deal with it.

Man I got a LOT of hidden files in there… ha I DO have a .profile from 2006, in the trash with it. Well, that didn’t fix it (maybe try empty trash). That neither. There is a .bash_history, but no mention of Preview. Lots of stuff in there about long ago stuff… it’d mod date is 2020, so am tossing it as well. Gonna try a reboot now.

Nah, stil there. Does it make any difference that it seems to defaults to tcsh? I tried with several other profiles, but still get the same message. I DO vaguely remember one could go with different shells, like tcsh and I think bash. Doesn’t seem to be any way to do that now?? BTW, no .bashrc on my whole machine. Nor .zshrc either. Also tried /Applications/Preview.app in spotlight, only showed up in a really old System Report file (.rtf from 2003). Got rid of that too.

Funny because there sure seems to be a Preview.app in /Applications, it has size, not a symlink! Got any other ideas?

I can’t seem to let this go, it’s really bugging me, I figured out how to run bash, got this:

Last login: Sat Mar 1 19:25:37 on ttys001
The default interactive shell is now zsh.
To update your account to use zsh, please run chsh -s /bin/zsh.
For more details, please visit Use zsh as the default shell on your Mac - Apple Support.
Pauls-Mac-mini:~ paulcons$

Do I want to follow their instructions? Oh, the window title bar shows “bash.”

Found an interesting page:

Got it running default to zsh and no message about Preview! Of course the question still lingers about is using that what I should be doing?

The “TC shell” or “tcsh” used to be the default shell in OS X. Along with the older C shell (csh), it uses a different set of startup files than shells like zsh and bash.

Take a look at the following startup files to see if there are any clues:

  • /etc/csh.cshrc
  • /etc/csh.login
  • /etc/csh.logout
  • ~/.tcshrc
  • ~/.cshrc
  • ~/.login

The ones in the /etc directory are system-wide files and probably shouldn’t be touched. Regarding the others, you may have some of them, all of them, or none of them.

2 Likes

The Settings in Terminal has an option to start a program or app on startup. See the screen shot below. In this example I have it set to open the tcsh shell but it appears that any app is eligible.

Sequoia 15.3.1.

1 Like

I found that already. Also a way to set the default shell, so now when I launch Terminal, I get the zsh shell by default (it HAD been tcsh). Seems Apple says this is “their” default shell.

So while I can now open terminal without being bugged like my OP screen cap, I am still curious abut 2 things. Is there any reason to use any shells other than zsh. Second, I am still curious about using tcsh giving me that error… I still can’t find where this “command” is located, I went through all that Davis S. said and I still can’t find it. I did not look for files in the /etc folder.

1 Like

If you’re looking in the Finder, it’s an illusion. The GUI “Applications” folder contains contents from the System volume (mounted as /System), the Data volume (mounted as root) and various “cryptexes” which are digitally-secured system add-ons.

If you look using command-line tools, you will see that the apps visible in the GUI actually existing in a variety of these locations. And tools/scripts that have hard-coded paths to apps need to have their paths pointing at the correct location.

This is almost certainly the same thing. Whatever was previously launching Preview is now generating errors because Preview is no longer in its expected location.

This happened a few releases ago. Although macOS still ships with the bash shell, Apple would like to get rid of it, probably for licensing reasons. Bash is released with a GPL license, so Apple must distribute any changes they make to it source code. Zsh doesn’t have such a requirement (although some of its components have GPL license terms.)

For most people, the two are effectively interchangeable.

This means that whatever was trying to launch Preview was doing so using a shell-initialization script used by Basn, but not used by Zsh.

Since you already checked for and did not find any ~/.profile or ~/.bashrc scripts, that wouldn’t be the cause. But there are other startup files. If you type man bash to pull up its documentation and look at the INVOCATION section, you will see the sequence of scripts it runs at startup:

  • /etc/profie - System settings. Run for “interactive login” shells - that is, the first one launched by a terminal or a remote login session for processing the commands you type.
  • ~/.bash_profile, ~/.bash_login and ~/.profile - Personal settings, run for interactive login shells. Bash will look for all three of these names, in the above order, executing the first one it finds, and ignoring the others, if they also exist…
  • ~/.bashrc - Personal settings, run for all interactive shells (those not used to drive scripts), whether or not it is a login shell.

In contrast, the Zsh startup (type man zsh and look for the STARTUP/SHUTDOWN FILES section) reads the following scripts (if they exist) at startup, in the following order:

  • /etc/zshenv - Sets up the global zsh environment
  • ~/.zshenv - In your home directory
  • /etc/zprofile - Only run for login shells
  • ~/.zprofile - Only run for login shells
  • /etc/zshrc - Only run for interactive shells
  • ~/.zshrc - Only run for interactive shells
  • /etc/zlogin - Only run for login shells
  • ~/.zlogin - Only run for login shells

If launched as sh (for backward-compatibility with the old Bourne shell), then instead of the above, it runs the scripts that sh would run:

  • /etc/profile - Global settings. Only run for login shells.
  • ~/.profile - Personal settings. Only run for login shells

Anyway, if you want to keep looking, the above should help you with your search.

3 Likes

Ha, I looked into /etc… very interesting, there certainly are some very, very old files in there that I can get rid of, but I know there’s some very important stuff in there so I demur on tossing. BUT I saw nothing at all w/tcsh in their file names. Did another global search, bingo I found something. ~/tcshrc. In there I see:

alias ls ls -alF !*
alias top top -u !*
alias ttop top -s 5 -u 20
alias pman man -t !^ | open -f -a /Applications/Preview.app/
alias tree find . -type d | sed -e 1d -e ‘s/[^-][^/]*//–/g’ -e ‘s/^/ /’ -e ‘s/-/|-/’

Going to try and move it elsewhere and see what happens. Or would it be better to just wipe out the line launching Preview?

Update… that file was from 2007! Moved it elsewhere, NOW running that shell in Terminal did NOT yield the error message. Oddly enough, it did not seem to re-create that file in ~/.

Can’t thank you enough David for all the help… at least I learned a bunch of things along the way!

2 Likes

If you don’t plan to use tcsh and/or don’t care about those aliases, it doesn’t matter. None of them are essential to shell operation. They look like personalizations to me, so I can’t really help you figure out where they came from. If you really want to be careful, the “safest” option would be to rename the file so that it doesn’t get evaluated when running a new TC shell. Something like “tcshrc.old” would be fine.

I would leave the files in /etc alone. Unless you are a careful expert, if things are otherwise working well, the risk of breaking something by messing aroung in /etc is much greater than the chance of making things better.

1 Like

You can also see this in the Finder. If you do a “Get Info”, you can see the actual location of each app. For example

I would not delete anything in /etc unless you are very very certain you know what you’re doing. Most system services keep their configuration files in there. The fact that a file hasn’t changed for a long time doesn’t mean it isn’t being used by something.

Bingo! That’s it. The file ~/tcshrc will run whenever you open a tcsh shell. That line beginning with pman is intended to present manual pages in a nicer-looking fashion. If it works as intended, then typing pman foo would pull up the manual page for foo, generate troff typesetting-sources from it, and feed that into Preview for display.

But if it used to work, it certainly doesn’t today. I tried it just now and Preview doesn’t open the content - it just asks me to open a file.

As for why you’re seeing the warning when opening a shell, I assume this is something tcsh is doing as a part of trying to install the alias.

Delete that one line from your ~/.tcshrc file and it will probably solve your problem.

The system won’t auto-create the file, because it’s a script that you are expected to write for yourself, containing code you think should be executed whenever a new tcsh shell is opened. Typically this is to do things like creating command-aliases (e.g. the code you cited), setting up important environment variables and other similar things. If the file doesn’t exist, it just means that you don’t want to customize the shell environment.

4 Likes

Correction. It’s because the lines are malformed. Whoever added them to your ~/.tcshrc file didn’t seem to understand how it works.

The tcsh alias command is of the form alias foo bar. This creates an alias foo, which when typed will execute bar. But certain special shell-interpreted characters will be processed by the shell when creating the alias, instead of being part of the alias’s text.

Specfically, the pipe (|) character is one such character. So when the shell run the following line at startup:

alias pman man -t !^ | open -f -a /Applications/Preview.app/

It is creating an alias where pman will call man -t !^, and any output from the alias command will get sent to Preview. This is almost certainly not the original intention for the alias, but it does explain why shells would launch Preview in the past and now produce errors.

The original author probably should have written:

alias pman 'man -t !^ | open -f -a /Applications/Preview.app/'

By surrounding the full command with single-quotes, the shell won’t process any of that text but will make it all part of the alias.

Of course, it still won’t work with modern versions of macOS.

Similarly, the tree alias is similarly malformed. As written, the tree alias will just call find . -type d. Everything after the pipe character (intended to process the output of that find command) gets executed as a part of alias-creation instead of being part of the alias command. But the expression includes single-quotes as well, which means any surrounding quotes also need special handling. This is probably what the original author intended:

alias tree "find . -type d | sed -e 1d -e 's/[^-][^/]*//–/g' -e 's/^/ /' -e 's/-/|-/'"

I suspect those last two lines (the pman and tree aliases) probably never worked as intended

Delete those lines. Or if you don’t want to lose the content, put a # character at the start of the line (making it a comment-line, which won’t be executed)

3 Likes

Choosing the “best” shell used to be the source of intense technoreligious wars, even moreso than the choice between Windows or Mac.

If you don’t already have a strong shell preference or a clear shell-specific idea of how you might want to customize your command-line experience, I don’t think there is a strong reason to use anything other than zsh as the default shell on a Mac.

In the Linux world, there is more variety in the usage of different shells, but the Bash shell is most commonly used. For the most part, that’s not a big deal, since the syntax and options are mostly shared between bash and zsh. Both attempt to be backwards-compatible with with the Bourne shell, which has been around since 1976. There are some important differences between bash and zsh, but unless you spend a lot of time on the command-line or write shell scripts extensively, you probably wouldn’t notice. Apparently, Apple switched to zsh over bash because of licensing reasons.

In my own case, my first in-depth exposure to UNIX was on Silicon Graphics systems that used csh/tcsh as the default interactive user shell, so I tend to “think” in csh syntax on the command-line. I was reluctant to switch from tcsh to zsh on my Macs simply because of my comfort with tcsh, but I haven’t run into any real issues since switching a few years ago.

3 Likes

I pretty much insist on my command files including “#!/bin/sh” as a first line. This makes moot the default shell selection. Some of my command files have been in active use since long before the zsh transition. Many others have been replaced by Howard Oakley (Eclectic Light Co) Tools.

3 Likes

Well, I did toss it, AND see Terminal seems to run just fine using tsch. And that file was not re-created… AND it was from 2007 to boot! Maybe to be safe I should get that file from my backup just for the hell of it.

That’s done, I got the file back where it came from with a .old designation. Now let see if everything works as I’d expect it to.

Yup, all looks good. The funniest thing is this seems to persist through many OS updates AND more than one migration to newer hardware. I think my Mini is the fourth machine I’ve had in that time. AND the migration to the Mini left out ~/Pictures, ~/Movies and ~/Music which I had to manually copy over.

Why bother switching at all? Configure your login to use what you’re comfortable with. I (like SGI) think that tcsh is the most convenient interactive shell, so I use that.

The Bourne shell (and its children, including bash, zsh and others) is more robust with respect to the kind of scripts you can write with it. But you don’t need to use it as your default command-prompt in order to use it for scripting.

Every script file on a Unix system has (or should have) a “shebang” as the first line of the file. This is a line consisting of "#! ", followed by the name of a program that will process the rest of the file. So if the file is a Bourne shell script, you would put “#! /bin/sh” at the top of the file. If the script uses bash extensions, you would put “#! /bin/bash” there.

And it works for any kind of script. So if it’s a Python script, you can put “#! /usr/bin/python3” as the first line, and the file will be run through the Python interpreter.

Every script file on a Unix system should always include a line like this specifying which shell should be used to interpret the script. If you don’t, you run the risk of all kinds of breakage because different people configure their accounts for different shells.

And, as I wrote above, it lets you make any source code for any interpretive language executable by simply setting the “x” permission on it (e.g. chmod +x foo). No need to explicitly launch it via the application (e.g. bash foo or python3 foo), and no need to use a magic filename extension to indicate the file type.

It’s been my experience that Migration Assistant just copies stuff like this over to new systems as you go, without making any changes. It’s the safest approach, since it can’t possibly know what you may have had in mind when you originally wrote the script.

What really surprised me on my system is when it copied over the /usr/local directory, where I put everything I compile from scratch. I fully expected that I was going to need to manually migrate everything in that location.

2 Likes

I agree with your whole post, but I thought I’d comment further on my decision to switch. As much as anything else, it was to see if this old dog could still learn some new tricks, especially since everyone around me uses bash and bash-like shells. The network effect, in action. I do still fire up tcsh on occasion for expediency when I’m in a hurry and bash syntax is slowing me down.

I also agree (violently) with the importance of separating interactive use from scripting use. In general, I’m very much on the side of using whatever you want as an interactive shell and sticking with your system’s /bin/sh equivalent for writing shell scripts, especially administrative scripts. (I put python and other languages in a separate bucket, but I agree with your approach there, too.)

1 Like

Oh, I agree. I have used both sh/bash vs. tcsh prefer the latter.

A little OT here but when I first took (unstudied, but passed) Comptia tests for ACN association- they had a couple Unix terminal questions that I answered as z not t,
Slight variance. Since I passed I didn’t care- I used to do a lot of terminal profile tricks back in early OSX days. (like NeXT and BeOS).