Is there a way to add an entry to OS X's /var/log/install.log file from within a shell script?
Optimally the method wouldn't require root access as I don't think I'll have it.
The problem I'm having is I'm executing a shell script as part of an installation-check (p15 of Apple's Distribution Definition XML Schema) step from within an OS X installer package via the Javascript System.run() command (p30 of Apple's Installer Javascript Reference), but I can't see any output from that shell script.
I know the shell script is executing, because when I use the "logger" command from within the script, my log text appears inside /var/log/system.log. But in order to get a complete picture of what's going on, I'd need to merge it by hand with /var/log/install.log, which is where the general output of the installer, and any Javascript logging I do, ends up.
Any help would be appreciated. I've tried using the "logger" command's -f flag to use /var/log/install.log, e.g.
logger -f /var/log/install.log sometext
...but no dice; sometext still gets added to /var/log/system.log.
Read up on bash scripting.
You can add a line to a file like this
echo "My line here" >> /var/log/system.log
If it gives a Permission denied error, you need root access.
OK. Long time passed, and I found out the following.
In normal scenarios, anything written by pre and post install scripts (mine are python and bash) to stdout will be logged by the installer daemon to the /var/log/install.log. I experimented various tools to create my installer packages, and they usually did this.
However, in my own deployment installer, for some reason, only things written to stderr get logged to the /var/log/install.log - so you might want to try that too.
A little late, but just had the same problem and was able to add logs to install.log from AppleScript using logger with the LOG_INSTALL facility:
logger -p 'install.error' "My error message"
That's not an answer per se, but maybe a hint? Installer man pages mention a "LOG_INSTALL facility", whose output is the desired /var/log/install.log
But what is this "facility" and where is it available - I can't find. I really need to write my pre/post script failures and specific scenarios to that log.
Related
The windows API provides GetCommandLine() which returns the cooked command line used to start a process.
For instance, if a console application is started with the command:
MyProg.exe > OutputHere
The command line seen by MyProg.exe will not include the portion
> OutputHere
I'd like to somehow get the command line exactly as it was. Is this possible ? and if yes, how ?
Suggestions in C and/or plain (no objects) Delphi greatly appreciated. Creative solutions welcome (hopefully, not requiring ring 0 code.)
Thank you very much for your help.
NOTE: I can tell if the input/output, etc has been redirected but, that is not what I'm looking for. I need the original/uncooked command line.
The redirection or piping of stdin, stdout and stderr is handled the command interpreter, typically cmd.exe. The interpreter parses the command and creates the necessary files and pipes, and then creates the one or more processes needed to implement your command.
The processes that are created have no knowledge of the original command, they only get that part of the command that is not related to piping and redirection.
So what you are trying to do is not possible, at least within your process. The only thing that knows the original command is the command interpreter.
Whether or not you can retrieve the full command line including the pipe commands depends on whether your start the program in a command window or for example using the "Run" command from the Start menu. If you use the "Run" command from the Start menu GetCommandLine actually retrieves the full command line including the redirection commands, but redirection does not work as it seems to be a feature of CMD.EXE.
As others have pointed out, what are you trying to achieve here / why do you need to capture the redirection commands?
I'm trying to run several sets of commands in parallel on a few remote hosts.
I've created a script that constructs these commands, and then writes the output in a local file, something along the lines of:
ssh <me>#<ip1> "command" 2> ./path/to/file/newFile1.txt & ssh <me>#<ip2>
"command" 2> ./path/to/file/newFile2.txt & ssh <me>#<ip2> "command" 2>
./path/to/file/newFile3.txt; ...(same repeats itself, with new commands and new
file names)...
My issue is that, when my script runs these commands, I am getting the following errors:
bash: ./path/to/file/newFile1.txt: No such file or directory
bash: ./path/to/file/newFile2.txt: No such file or directory
bash: ./path/to/file/newFile3.txt: No such file or directory
...
These files do NOT exist but will be written. That being said, the directory paths are valid.
The strange thing is that, if I copy and paste the whole big command, then it works without any issue. I'd rather have it automated tho ;).
Any ideas?
Edit - more information:
My filesystem is the following:
- home
- User
- Desktop
- Servers
- Outputs
- ...
I am running the bash script from home/User/Desktop/Servers.
The script creates the commands that need to be run on the remote servers. First thing first, the script creates the directories where the files will be stored.
outputFolder="./Outputs"
...
mkdir -p ${outputFolder}/f{fileNumb}
...
The script then continues to create the commands that will be called on remotes hosts, and their respective outputs will be placed in the created directories.
The directories are there. Running the commands gives me the errors, however printing and then copying the commands into the same location works for some reason. I have also tried to give the full path to directory, still same issue.
Hope I've been a bit clearer.
If this is the exact error message you get:
bash: ./path/to/file/newFile1.txt: No such file or directory
Then you'll note that there's an extra space between the colon and the dot, so it's actually trying to open a file called " ./path/to/file/newFile1.txt" (without the quotes).
However, to accomplish that, you'd need to use quotes around the filename in the redirection, as in
something ... 2> " ./path/to/file/newFile1.txt"
Or the first character would have to something else than a regular space. A non-breaking space perhaps, possible something that some editor might create if you hit alt-space or such.
I don't believe you've shown enough to correctly answer the question.
This doesn't look like a problem with ssh, but the way you are calling the (ssh) commands.
You say that you are writing the commands into a file... presumably you are then running that file as a script. Could you show the code you use to do that. I believe that's your problem.
I suspect you have made a false assumption about the way the working directory changes when you run a script. It doesn't. You are listing relative paths, so its important to know what they are relative to. That is the most likely reason for it working when you copy and paste it... You are executing from a different working directory.
I am new to bash scripting and was building my script based on another one I had seen. I was "running" the command by simply calling the variable where the command was stored:
$cmd
Solved by using:
eval $cmd
instead. My bad, should have given the full script from the start.
I saw >_ in bash shell icon in mac and was wondering what it will do.
I tried performing the command but I was not able to figure out what happened. My command prompt silently came again.
It should be doing something, that's why it is in the icon for terminal.
Do anyone know what it does and can it be used for something?
Running >_ will successfully run (nothing), redirected to a file named _. It's not terribly useful, but that's what it does. The most useful empty redirection I've seen is to empty the contents of a file with it:
> /var/log/app.log
which, if app.log is not open by another process, will result in /var/log/app.log being empty.
I'm trying to use a Bash script to take certain log entries and generate a more user friendly notification email via exec with swatch. However, what I'm finding is when swatch picks up the corresponding log file lines to match for a specific application, the Bash script is erroring out with sh: script: No such file or directory.
This seems to be due to the log line in question outputting something like:
[2017-05-22 20:00:41] somehost someapp[3999]: INFO: <script>: bad stuff happened bruh
I've tested the script out with output from things like rsyslog to /var/log/messages and secure, which don't cause problems. This specific application I'm trying to make these notifications for is only problematic because the log lines themselves include <script>, which I can't exclude. Specifically, this seems to trip up with just <script as I've messed around with removing chars in those log lines that might be interpreted as something besides text.
Any ideas on how to not get the Bash script to try to interpret <script> as a file/directory in the original log? It's even fine if the suggested answer is to simply rip that out of the line. I've tried using sed -i 's/\<script\>//g ${#} to remove <script> to strip and store to a temp variable with the intention of doing something like: echo -e "${plainenglish}\n\nThe original log message is:${logline}" >> $outputfile but I get the same error noted above.
Edit: More info. The problem application in question is Kamailio, where most of the logging from routing execution is written by the xlog module. By default, xlog shoves <script> in front of everything you log. The module does include a parameter override (modparam) for prefix, which defaults to <script>.
I realize this is a bit specific for question and solution, but here's a summary followed by suggestion:
-Using Kamailio (SIP server/proxy, etc.) with xlog configuration logging calls to some logfile (e.g.: /var/log/kamailio)
-Using swatch or some tool to grab specific Kamailio logs with the intent of notifying, such as routing failure or suspicious requests received (e.g.: +18928751123#1.1.1.1:5060)
-Using Bash shell script to sanitize/normalize the corresponding log line in some manner for dispatch.
The solution: set xlog's prefix modparam to something that will not be interpreted by Bash as a legal command (script is a legal command) when attempting to process the log lines.
It seems Bash processing gets thrown astray as soon as it hits the <script> line in the default xlog produced logfile lines.
I am looking to automate an interactive install process with ansible. This install does not have a silent install option or does not take command line arguments for the interactive questions. The question involve setting a folder location, making sure folder location is right etc for which answers might be default or custom.
I looked into the expect module of ansible but seems like it does not solve my purpose.
- expect:
command: passwd username
responses:
(?i)password: "MySekretPa$$word"
I don't need the command but it's required. Instead I am looking for something that could regex Are you sure you want to continue [y|n]? [n]: for which I want to send the default out By sending return or typing n as a response and for example Backup directory [/tmp] for which the response would be Carriage return.
I don't need the command but it's required. Instead I am looking for something that could regex Are you sure you want to continue [y|n]? [n]:
The module requires a command because you have to run something to get any output.
You obviously do have a command in mind, because you've run it manually and seen the output it produces. That's what you should be plugging into the module.
Alternatively, you can write a pexpect script yourself and use the command or shell modules to run it.
I've figured out a way that works for me. I piped in the arguments to the shell script which when run manually needs the answers. Like ./shell.sh <<< 'answer1\nanswer2\n' which works perfectly for me. This I have added to the task.