There's an app I've started working on, that regularly logs to the console a lot of stuff, and it's really not convenient to use the console for additional debug logs. I don't want to erase these logs, because there are a few people that are maintaining these logs, and it might be important to them.
So I actually need to to write my debug stuff to a different place. one option is to write it to a file and watch it in Terminal using tail command, but an iOS app can only write inside its folder which, when using a simulator, is always changing each time I run the app. and I don't want to change the path int the tail command every time - I want a fast process.
Does anyone have an idea for such external log place that I can use easily?
Here's how to make it easier to find and tail your log file when running in Simulator (I use this myself):
1) Add the following code to your home directory's .bashrc then log out and back in again.
xcodelog()
{
find . -name xcode.log -type f -print0 | xargs -0 stat -f "%m %N" | sort -rn | head -1 | cut -f2- -d" "
}
2) Start your app in Xcode's simulator, such that at least something gets logged to your file. Oh, and the file your app is logging to needs to be named "xcode.log" unless you want to change the filename in the above code.
3) Open terminal and switch to your ~/Library/Developer/CoreSimulator directory. Then perform the following command (it displays the last 100 lines of it along with anything new you dump to it).
tail -n 100 -f $(xcodelog)
So the above command hunts for that file among all your simulator devices and their apps, hunting down the most recent "xcode.log" file you've written to (among all apps and devices in entire CoreSimulator subdirectory system).
To clear the most recent xcode.log file, you can do this command:
cat /dev/null > $(xcodelog)
I switched to this approach for all my logging when Xcode 8 lost support for plugins, along with the very fine XcodeColors plugin that would do ANSI color logging into Xcode's console. So I changed my log system to output colors that terminal would support when doing a tail of a file. So I can spot errors in red, warnings in orange, user step logging in yellow, and various degrees of important other info in progressive shades of gray. :)
Related
At some point, whenever I use vi from the command line (windows 10/WSL) it starts up in insert mode, meaning that everything I usually do to navigate ends up adding stuff to the file, wasting time having to clean it up.
I didn't have a vimrc file, and there doesn't seem to be anything in my bash rc files to modify vi behavior. Any ideas what I may have done or any ideas how to stop this behavior? I'm using Ubuntu-20.04
FWIW, adding a .vimrc file with tab related settings didn't change it's behavior. I looked at the /etc/vimrc file, and nothing inside it seemed relevant.
After plowing through google search and trying everything I understand about configuring 'vim' and doing comparison tests, I think:
This behavior is specific to Windows Terminal when opening a WSL terminal. Using WSL's "native" terminal (i.e., clicking the "Ubuntu 20.04 LTS" menu in the "Start" menu) doesn't have this problem.
My original motivation for switching to Windows Terminal is for its multi-tab feature. But this new behavior is crazy -- it works against years of my muscle memory of using "vi", and I'm almost certain that one day I'll accidentally update some configuration file while reading it in "vi". And, I cannot re-train a new muscle memory because all the rest of the UNIX world (e.g., when I SSH into a remote server) hasn't changed. This is like constantly switching between a Mac keyboard and a PC keyboard where the Ctrl key, etc., are in different places.
My solution: I switched to MobaXterm. It has multi-tab support, and is actually richer in features compared to Windows Terminal.
Please run the following:
alias | grep vim
sudo find / -name .vimrc 2>/dev/null
These commands should show you all the places to check, change the alias or fix the .vimrc files found.
Do you find it always going into edit mode, when you vim a file directly and when you use vim as the git commit editor for example?
EDIT:
You could also try which -a vim or whereis vim to see if you have multiple versions. Or failing that sudo find / -name vim 2>/dev/null
here is a better solution. I downloaded the binary.
https://github.com/lxhillwind/vim-bin/releases/tag/v9.0.0978
Put the vim command in /usr/bin/vi
Put the runtime in:
/usr/local/share/vim/runtim
sudo apt remove vim vim-common vim-runtime vim-tiny
sudo apt purge vim vim-common vim-doc vim-runtime vim-tiny
The second line actually gets rid of residual-defaults.
There is also a defaults.vim someplace on the system. I just nuked it.
I went through and made sure there were no aliases or vi or vim configuration files, but still no luck.
This is a horrible solution, but the only thing that is keeping my sanity right now.
vi -c ":imap jj "
You can alias it in your .bashrc. Looking into better solutions.
I would like to start two different services in my Docker container and exit the container as soon as one of them exits. I looked at supervisor, but I can't find how to get it to quit as soon as one of the managed applications exits. It tries to restart them up to three times, as is the standard setting and then just sits there doing nothing. Is supervisor able to do this or is there any other tool for this? A bonus would be if there also was a way to let both managed programs write to stdout, tagged with their application name, e.g.:
[Program 1] Some output
[Program 2] Some other output
[Program 1] Output again
Since you asked if there was another tool... we designed and wrote a powerful replacement for supervisord that is designed specifically for Docker. It automatically terminates when all applications quit, as well as has special service settings to control this behavior, plus will redirect stdout with tagged syslog-compatible output lines as well. It's open source, and being used in production.
Here is a quick start for Docker: http://garywiz.github.io/chaperone/guide/chap-docker-simple.html
There is also a complete set of tested base-images which are a good example at: https://github.com/garywiz/chaperone-docker, but these might be overkill and the earlier quickstart may do the trick.
I found solutions to both of my requirements by reading through the docs some more.
Exit supervisord on application exit
This can be achieved by using a custom eventlistener. I had to add the following segment into my supervisord configuration file:
[eventlistener:shutdownevent]
command=/shutdownhandler.sh
events=PROCESS_STATE_EXITED
supervisord will start the referenced script and upon the given event being triggered (PROCESS_STATE_EXITED is triggered after the exit of one of the managed programs and it not restarting automatically) will send a line containing data about the event on the scripts stdin.
The referenced shutdownhandler-script contains:
#!/bin/bash
while :
do
echo -en "READY\n"
read line
kill $(cat /supervisord.pid)
echo -en "RESULT 2\nOK"
done
The script has to indicate being ready by sending "READY\n" on its stdout, after which it may receive an event data line on its stdin. For my use case upon receival of a line (meaning one of the managed programs has exited), a SIGTERM is sent to the supervisord process being found by the pid it leaves in its pid file (situated in the root directory by default). For technical completeness, I also included a positive answer for the eventlistener, though that one should never matter.
Tagged output on stdout
I did this by simply starting a tail process in the background before starting supervisord, tailing the programs output log and piping the lines through ts (from the moreutils package) to prepend a tag to it. This way it shows up via docker logs with an easy way to see which program actually wrote the line.
tail -fn0 /var/log/supervisor/program1.log | ts '[Program 1]' &
I just enabled ParseCrashReporting in my app, and now when I build the app, Xcode stays on "Running 2 of 2 custom shell scripts" (i have another simple script for HockeyApp integration, placing it before that does not change anything).
My script is below:
export PATH=/usr/local/bin:$PATH
cd ~/OneDrive/AppName
parse symbols AppName -p "${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}"
My AppName folder is also where I started my parse cloud repo, it contains the folders cloud, config and public. I tried changing the path to AppName/cloud but no change.
Xcode stays running that script for a long time...i've waited 10 minutes for it before and it doesn't continue beyond that. Once I stop the build, I get an error: Shell script invocation error:
Uploading iOS symbol files...
Command /bin/sh failed with exit code 1
I assume the error just shows because I cancel the task. Why would this be sticking like so? I have looked at several questions on parse crash reporting and have not seen any similar issues.
Just use the following script instead, I just tested it and it works:
echo "Parse Crash Reporting"
export PATH=/usr/local/bin:$PATH
CLOUD_CODE_DIR=${PROJECT_DIR}/helloKittyAdventureTimeCloudCodeFolder
if [ -d ${CLOUD_CODE_DIR} ]; then
cd ${CLOUD_CODE_DIR}
parse symbols YOUR_PARSE_APP_NAME --path="${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}"
echo "Finished uploading symbol"
else
echo "Unable to upload symbols"
fi
IMPORTANT:
The following line needs to be changed based on your folder name, that's it, keep everything else the same:
CLOUD_CODE_DIR=${PROJECT_DIR}/helloKittyAdventureTimeCloudCodeFolder <===this should be the
name or your own folder!!, so, if your folder is named theAdventuresOfCaptainCookCloudCode,
then you would type this:
CLOUD_CODE_DIR=${PROJECT_DIR}/theAdventuresOfCaptainCookCloudCode
Also, one more thing to note, you don't need the echos and such if your run this as a Run Script in Xcode, but you don't have to take them out either, you can just run it like this and you won't have a build error.
One more thing, make sure to change YOUR_PARSE_APP_NAME to the name or your app, sorry about that, this also needs to be changed
I am developing web applications using Ruby on Rails and Sublime Text 3 on OS X 10.8.4. I recently installed the package RubyTest. The tests only work when Sublime is launched using the command
subl
in terminal. Otherwise I get the error message:
/bin/sh: rspec: command not found
I think that's meant to be the case; that's implied in RubyTest's readme file on github.
However I'd like to retain the ability to launch from the dock. Is there a way I can do this?
Unfortunately, OSX applications do not pick up on your $PATH variable set in Terminal. To change the internal PATH settings in Mountain Lion (this method hasn't been tested with previous versions, although it should work), you'll need to edit /etc/launchd.conf:
Make sure you have admin privileges.
Open Terminal or your favorite substitute and see if there's anything in the file /etc/launchd.conf:
cat /etc/launchd.conf
If you get an error like
cat: /etc/launchd.con: No such file or directory
then continue with the next step. If the cat command does display some content, copy it to the clipboard.
Create a new text file with the following content, modified to fit your needs:
setenv PATH /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/Users/YourUserName/bin:/path/to/gems/bin
If the cat command displayed some content in the previous step, paste it into the new file before the setenv PATH command. If it already contains a setenv PATH command, just modify it to add the directories you need, such as /path/to/gems/bin
Save the new file in your home directory (/Users/YourUserName) as launchd.conf.
Go back to Terminal and enter:
sudo mv ~/launchd.conf /etc
to use admin power to move the new file to /etc, replacing anything that was there before. Depending on your previous usage of the sudo command, you may get a short "be careful doing what you're doing" message, but either way you'll need to enter your password. /etc is not directly accessible through the Save dialog unless you're a real power user and know how to get around OSX's file system restrictions.
Reboot your computer
And you should be all set. If you're interested, launchd and launchctl use the csh/tcsh syntax, so you can't use the bash/zsh export PATH=/usr/local/bin:... format.
I am trying to automate a test session from jenkins using Frank.
this is the error message I receive.
(Frank::Cucumber::FrankNetworkError)
./step_definitions/test_steps.rb:30:in `/^I navigate to button V\303\244der$/'
test.feature:41:in `When I navigate to <link>'
| Radar | Norrland |
*********************************************
Oh dear. Your app fell over and can't get up.
*********************************************
Jenkins checks out the code from git, besides this I have added a shell command as follows.
cd ios #<--this is so that I go to the root folder, the one with the .xcodeproj project
frank setup
frank build
frank launch
mv features/*.feature Frank/features/. #<--- this is the testscript
mv features/step_definitions/*.rb Frank/features/step_definitions/. #<--here it is moved to the newly created frank/features & Frank/features/step_definitions folder
cd Frank/features
cucumber test.feature
Everything is built the way it should and if I go to the server
and manually type the last row from my shell command will the tests be executed.
Best Regards
I have personally had many problems running Jenkins on Mac. Especially if you used the Jenskins Mac image installer, Jenkins is always run under the "jenkins" user that is created during installation.
This has given me many headaches with running cucumber from inside jobs or for starting the iOS simulator.
I have finally learned to start Jenkins under my own user, like this:
"nohup java -jar /Applications/Jenkins/jenkins.war --httpPort=8080
Since then, I was able to run cucumber without any problems. Hope this helps.
This happens every time your application crashes. When the application crashes, frank stops receiving events and cucumber ends with the error you see.
There are two possible reasons:
You have a bug in your app that made the app crash
Frank has a bug that made your app crash
You should inspect the crash/application log to see the exact reason.
I learned that is very helpful to capture the application log by the jenkins job, e.g.
function grab_log_and_fail {
APP_NAME = "MyApplication"
# get the PID of the last process with the given name
PID=$( cat /var/log/system.log | grep "$APP_NAME\[" | tail -n 1 | sed -e "s/^.*$APP_NAME\ [\([^\]*\)\].*/\1/g" )
# grab all the messages from the process with the PID
cat /var/log/system.log | grep "$APP_NAME\[$PID\]" >"$WORKSPACE/$APP_NAME.log"
#fail the job
exit 1
}
You can call it using
cucumber test.feature || grab_log_and_fail
(will grab the log only if cucumber ends with an error)