I have been working with two terminal windows in my Mac (dev/prod), both had shown the commands and results history (scrolling up) for the last 6 months of work, which was very helpful to run periodic commands and to check past errors.
Yesterday I turn off my mac and closed both terminal windows manually, but today when opening the terminal it has no history at all. There is a way to recover the windows with all the history for past commands and their results?
I know there is a .bash_history file but it only shows commands typed but not the results.
Thanks in advance.
Bash's history only store executed commands, not their output, and only a limited number of them (usually 500, as defined by environment variable HISTFILESIZE). This won't help in your situation.
From what I can see, it appears that Terminal store save window's state (including console history) inside directory /Users/<user>/Library/Saved Application State/com.apple.Terminal.savedState/. Files in this directory are modified in real time whenever new events occurs in the terminal window, and unless I am mistaken, should be included in Time Machine backups. Therefore, it seems that if you can restore files in this directory from some former backup, you should get back your history. You could even try some "file undelete" tools in that directory, though these tools are rather rare on OS X.
The procedure for this should be that you first quit Terminal, then restore the whole directory (for example using Time Machine), then simply launch Terminal. These saved state files use a custom binary format, that you can't be read otherwise than by the Terminal program itself.
By the way, it might be worth mentioning that you can, at anytime, save the content of a Terminal window to a text file, from the Shell menu. You might consider doing it periodically, in the future, given that your terminal's history appears to have some significant value...
if using zsh check your /etc/zshrc for the history file location, mine has
# Save command history
HISTFILE=${ZDOTDIR:-$HOME}/.zsh_history
HISTSIZE=2000
SAVEHIST=1000
also check your ~/.zshrc incase the defaults for these have been changed
Related
I am fairly new to Mac OSX, and am trying to create an .app file to run in the Applications folder. I'm using MacOS Big Sur, and this will just be run on a Mac (it doesn't need to be cross platform). There is a jar file that executes by running a shell script, as well as a few extra resource files, so ultimately I'd like to bundle this all together in something like a dmg so that I can share it easily with a few other people.
I followed the advice given here and here to set it all up, and almost everything works. The program starts when I double click on the .app file, but without a terminal window. Unfortunately I need the terminal window to open because I use it to log messages to the user.
Terminal is the default app for the shell script, and a terminal does open when I run the shell script directly by double-clicking on it. The script file works with an .sh extension and without one, though I get an error trying to run the .app if the script has an .sh extension. Everything has execute permissions. I went through the Info.plist docs but couldn't find anything about the Terminal. I also tried creating the .app with Automator, but with the same result.
Any suggestions would be very much appreciated, as at the moment I'm completely stuck. As I said, ultimately I want to have a way of sharing this with others who may not be very computer-savvy (e.g. they're used to just downloading things from the App Store and wouldn't be able to install things using the command line). So if I'm going about this all wrong or there's an easier way, then let me know that too.
Unfortunately I need the terminal window to open because I use it to log messages to the user.
If this is all you want the Terminal app for then you don’t need it all.
The Terminal app is a GUI app which runs a shell using standard OS calls, passes keyboard input to that shell (and hence any commands it in turns invokes) via a pipe, and reads the output of the shell (and hence...) and displays it in a window.
You can run your shell script direct from your own app, collect the output, and dimply that output in a window in your app.
In Objective-C the classes you want to look up are NSTask, to run a shell passing it your shell script, and NSPipe, to create pipes needed.
There are plenty of Q & A’s on SO about NSTask/NSPipe, here is one and here is another which uses Swift.
Note that both of the above read all of the output before converting it to a string which can then be displayed in a window or otherwise processed. This is not required and if you have a long running shell script and wish to display output as it runs you can read shorter chunks from the pipe. Read the documentation to see how to do this.
I'm posting my solution in case it helps anyone in the future. As the comments/answers said, what I really needed to know was how to get my app to open a terminal window. Obviously by creating the app manually (creating the folder structure and minimal Info.plist) I was missing some key elements.
I tried to generate one using Xcode. I'm sure it's pretty straightforward, but I got bogged down trying to work out the Swift code.
What worked for me was creating an AppleScript using Script Editor. The script simply tells the Terminal program to run my bash script:
tell application "Terminal"
do script "/Applications/{name of app}/Contents/MacOS/run.sh;exit"
end tell
The key is that Script Editor can save this as an app to the Applications folder, which means it creates the necessary folder structure and files. After that I could just copy my program files into the MacOS folder, which is where my bash script looks for everything.
One option might be to give the script file the extension .command, e.g., and then open that, e.g.:
open myscript.command
The myscript.command file needs execute permissions (chmod a+x myscript.command).
These .command files can also be double-clicked in Finder to execute them in a new Terminal window.
I'm wondering whether others have experienced this issue (below in bold) and/or found a workaround: in macOS (any version that I've tried which provides Terminal access, so I'm assuming OS X on up; on any hardware), a Terminal or iTerm2 window gets named with the active top-level process until it ends or you quit it. Expected behavior for all systems with Terminal access, right?
When using SSH in Terminal or iTerm2 on macOS, the name of the remote machine populates the top of the window. Also expected. The unexpected comes when you exit out of the SSH session, and the name of the remote machine you had SSH'ed into persists in the window banner; there is no more visibility in the window banner of your current top-level running process, until and unless you close the window (losing some access to command history), and open a new window.
I've never seen this process-stuck behavior on the banner of a Terminal window in any other OS; various forms of Terminal on Linux distros exit out of SSH and get back to showing the top-level running process fine, as does CMD or PowerShell in Windows. What's going on with macOS, and why has this behavior never been addressed, at least as for as my limited DuckDuckGo-fu (or !G-fu) can find?
Has anyone else experienced this?
Insight welcome. Thanks!
There's no "process stick" going on.
Let's address several things here.
First, please note... "shell" != "terminal", and if you think it does, you are mistaken.
You state:
When using SSH in Terminal or iTerm2 on macOS, the name of the remote
machine populates the top of the window.
Yes, if the remote shell sets the terminal window title. Usually in a prompt. Sometimes in a shell initialization rc file. With ksh you even see people overloading things like cd(1), which is a little silly.
Then you state:
The unexpected comes when you exit out of the SSH session, and the
name of the remote machine you had SSH'ed into persists in the window
banner
Because the remote shell set the title of the terminal window and the local shell does not reset it when it regains control.
And finally:
What's going on with macOS, and why has this behavior never been
addressed, at least as for as my limited DuckDuckGo-fu (or !G-fu) can
find?
If you want whatever shell you are using to do something, configure it to do that thing. Otherwise, it will not do that thing. There's nothing to address... it's not broken.
macOS default init for ksh doesn't set any prompt at all, for zsh all that's set up is user name, machine name, and current $PWD, and bash is the same. None of them set the terminal window title.
Seems rather obvious what's going on.
So. If you want your terminal window titles to reflect this information:
the local shell needs to set the window title
the remote shell(s) need to set the window title
It seems you have the second one handled, so fix the first one. Most people do it by adding control codes to the shell prompt so that it changes the window as reliably as possible.
You may find this reference helpful.
Whenever I start a new session in PhpStorm embedded terminal it doesn't have any history of previously entered commands and by pressing Up key it usually shows some command I executed ages ago via macOS terminal.
Is it possible to make the embedded terminal preserve history of commands, that were entered in another embedded terminal before.
Not possible currently, please follow IDEA-155571 and linked tickets for updates
I started using vim for my programming projects (mostly Ruby) and mostly everything works just as I want but I have a problem with compiling.
Lets say I am working on a Ruby script and I want to run it. I type :ruby sometging.rb (mapped to some other key). Then vim opens a new cmd.exe window and runs 'ruby something.rb'. Then it waits for me to press ENTER to close the window and continue working on the script.
Is there a way to configure vim on windows so that it always runs the script I'm working on in a separete window (always the same one, if none exists => open one), and not ask me to confirm with enter?
Don't know about gvim, but in normal vim you could put something like
map R <ESC>:tabnew<CR><ESC>:;%!ruby filename.rb<CR>
in your ~/.vimrc which would execute a Ruby file in a newtab when pressing R in command mode.
I've not used Ruby, but for I've found Dr Chip's RunView plugin really useful for running other interpreted languages.
Once it's installed, you can enter:
:RunView! <interpreter>
(where <interpreter> is presumably 'ruby' in your case) and it will open a (vertically if you include the !) split window with the output from passing the contents of the current window to the interpreter. Each time it is run, a new result log is appended to the end of the file (with a date and time stamp separating them).
If you have any issues with it, I'd recommend you contact Dr Chip via the Vim mailing list: he's very helpful (in fact he wrote the original version of RunView in response to a request I made on the mailing list).
This isn't exactly perfect but I use this to launch Python scripts.
command -nargs=* PY3 !start cmd /K Python.exe "%:p" <args>
It starts up a window that stays alive and doesn't interfere with my VIM window. Unfortunately it doesn't load it into an existing window.
On my computer at work, any time I open a file located on a network share, GVim becomes completely unusable. Scrolling through the document can take 15 seconds to go one "page". Even using the movement keys to go from one word to another can take 2 to 3 seconds. This seems to be a new behavior, but for the life of me I can't remember changing anything that would cause it. I'm under the impression that Vim doesn't actually access a file except on open and on save. Is that right?
There are a few factors which may affect this.
First, make sure you have Vim setup to prefer storing the swapfile locally. If your $HOME is on a local drive, I tend to put this in my vimrc (which will either be at $HOME\_vimrc or $VIM\_vimrc). Make sure you create that directory, otherwise Vim will continue to use one of the other directories in the list.
set directory^=$HOME/tmp
This prepends the $HOME/tmp directory to the start of the list that Vim checks for where to place swapfiles.
Second, do the same for the backup file that Vim creates. Same situation as above but the option you'll be changing is backupdir instead of directory.
Third, make sure you disable the matchparen plugin. This plugin is new to Vim 7, so you may be used to using an older version of Vim. This causes frequent scanning of the file for matching parens, braces, etc. which can drastically slow Vim down when the file is on a network share. Again, this should go in your vimrc.
let g:loaded_matchparen = 1
If you only want to disable the plugin temporarily, you can use the command :NoMatchParen and then :DoMatchParen to re-enable it later in that Vim session.
Finally, if none of those help you can always copy the file locally and edit it.
Swap file has nothing to do with it. I have my swap file local and still have the problem. I use Process Monitor from SysInternals.com and it revealed bad behavior when attempting to open "\server\TestTool\foo\ReadMe.TXT"
It first attempts a CreateFile (aka, Directory open) on "\serve\". Notice the last character is missing. This will cause 4 seconds to time out with "OBJECT PATH INVALID".
Then it tries CreateFile on "\server\TestToo\". Server name is correct by the last letter of "TestTool" is clipped. Again, a 3 second time out with "BAD NETWORK NAME".
Finally it gets it right and calls CreateFile on "\server\TestTool\" which works right away.
Then CreateFile on "\server\TestTool\foo" which works right away.
Then CreateFile on "\server\TestTool\foo\ReadMe.TXT" which works right away.
WHY is it trying bad names for the server and the root directory??? What madness is this?
I fixed this issue after setting HOME path by force in advanced system settings.
(Your current HOME path would be a network directory.)
Control Panel > All Control Panel Items > System > Advanced system settings > Environment variables
Press "New..."
Variable name: HOME
Variable value: c:\Home\ **<-- Type your home directory**
A follow up on jamessan's answer: to disable the plugin automatically when you edit files on a share, put this line in you _vimrc
autocmd BufReadPre //* :NoMatchParen
You could consider installing LargeFile plugin. It disables a couple of features impacting the performance.
Having a similar issue as David Anderson, but no solution yet.
When loading \\ServerName\A$\B\C\File.txt Vim will do:
Open \ServerName\A$\B\C\File.txt
Then it does many loops like:
CreateFile \ServerName\A$ <-- Each taking roughly 1 sec
QueryDirectory \ServerName\A$\B
QueryDirectory \ServerName\A$
QueryDirectory \ServerName\A$\B\C
QueryDirectory \ServerName\A$\B
To compare with Notepad++ which loads files almost instantaneously there are more lines and Notepad++ never queries \\ServerName\A$.
Also the duration (Duration column) written in Process Monitor is low, but the time taken by Vim seem quiet high (Time of Day column) for the CreateFile \\ServerName\A$.
I've no plugins installed as far as I know and followed other tips to speed up network shares loading.
Note: The dollar is in the path. More weird is that Vim will load very fast on more recent Windows Server (2008 instead of 2003) with the same folder structure.
I had the same problem (slow gvim editing over network drive) and have fixed it. It was for me -- no kidding -- the titlestring.
Background: I use a vertically arranged taskbar with Windows 10. This has the advantage that my open windows behave like a growing stack from top to bottom. For example, see here some currently open windows with how-to-run.txt as a network file:
With that it makes sense, that the filename is going first in the window title of gvim and the path goes after that. So I used exactly the titlestring in my vimrc, which is still officially recommended in the help file vim81/doc/options.txt, line 8202:
set titlestring=%t%(\ %M%)%(\ (%{expand(\"%:~:.:h\")})%)%(\ %a%)
For local files that's ok, but for network files this is way too slow.
Now my fix:
set titlestring=
Same effect (filename first), but now gvim runs very fast for remote files as well!
BTW, I also tried all the above mentioned recommendations (directory, backupdir, matchparen, disabled all the plugins, tried the LargeFile plugin although I observed the slow gvim also for small files, etc.). I also changed my statusline to something really simple.
It all had no effect for me. But the funny titlestring...