Hey.
I'm trying to launch Instruments from shell with iPhone specified as target. As for this apple doc I should be able to specify target with '-w' parameter but I don't know what should be there.
I've tried iPhone name, I've tried its UUID but nothing worked - constantly I get 'Unknown hardware device specified'. I also checked content of some saved trace document, but inside I see UUID of the iPhone. Maybe it is some prefix/suffix that should be added to the UUID ?
In the end i would like to get the following working:
instruments -t /Users/user/Template.tracetemplate -D /Users/user/res.trace -w iPhoneID AppName
The following command worked for me(taken from http://lemonjar.com/blog/?p=69):
instruments -t /Developer/Platforms/iPhoneOS.platform/Developer/Library/Instruments/PlugIns/AutomationInstrument.bundle/Contents/Resources/Automation.tracetemplate <full_path_to_application> -e UIASCRIPT <path_to_script.js> -e UIARESULTSPATH <output_results_path>
There a few important things to note though:
the -w parameter is not required unless you want to run the scripts on your device. If you want to run your scripts on the simulator, simply omit this parameter from the command.
full_path_to_application is the path to your .app file that is created by your simulator. For me, the path was
/Users/fwasim/Library/Application Support/iPhone Simulator/5.0/Applications/AA6BA2E1-D505-4864-BECC-29ADEE28194D/name_of_application.app
this path might be different for anyone else depending on what iOS version are you running on your simulator. Also remember to put this path in double quotation marks.
The path_to_script.js should be the FULL PATH to where your automation script written in javascript is saved. Also remember to put this path in double quotation marks.
Lastly output results path is the path where you want to save the output results. Also remember to put this path in double quotation marks.
These were the points I had been missing on and thus was getting some of the errors mentioned above.
The hex "Identifier" value you find in the Organizer in the device's general information pane should work.
Related
On OS X, I'm looking for a command line which would show the known path of a bundleIdentifier from Launch Services point of view.
If there're several bundles with same id, my app keep looking for a trashed one, or copied, and it's hard to troubleshoot without a command like "launchctl .... mybundleId"
In swift, I've found:
let launchdPathToHelper = NSWorkspace.sharedWorkspace().absolutePathForAppBundleWithIdentifier(bundleIdHelper)
This helps me and gives me the answer, but sure there's a command line for that.
Thanks!
So I have a script that takes an input and prints whatever. It needs access to a file written by a third party. My Xcode project structure is just two files, main.swift and ThirdParty.swift. If I just run it from Xcode main.swift happily sees ThirdParty.swift and I'm apply to instantiate an object defined within. When I run from the command line it cannot find ThirdParty.swift (which is pretty much to be expected; how would it know it's there?).
None of the command line options to pass to /usr/bin/swift seem to be appropriate for pointing to a file I'd like to use and pointing it to the current directory doesn't work either. Is this even possible or should I just give up?
The ideal end result is the ability to do something like:
./main.swift --option1 --option2 thing
But an acceptable place to end up would be:
swift -X ThirdParty.swift main.swift --option1 --option2 thing
Where X is whatever option I need to be passing in.
You can't pass two files into "immediate" mode (swift REPL mode) but you have several other options:
Combine the files together on the fly into a temporary file (with e.g. /bin/cat)
Compile the two files into a normal binary with swiftc.
I recommend option 2, though it means every time you change the code you'll need to recompile, and the binaries it creates aren't portable between OS X and Linux.
I am having this script to find a file and select it
set filePath to ("filePath.ext" as POSIX file)
tell application "Finder"
if (exists filePath) then
select filePath
activate
else
display alert "File " & filePath & " does not exist"
end if
end tell
it is working perfect well on Mac os x 10.6.x (LION) but when I try to run this script on Mac os x 10.5.x (snow-leopard) it is selecting file but taking too much time. Any suggestion how can I make this code work fine on both versions of Mac.
Thanks in advance :)
EDIT:
I am selecting file from a network drive and hostel system is having a Windows Os. All systems are located in the same network.
The reveal command may be of assistance to you. It simply locates a file in the finder, opens a new window if necessary, and then selects the file—all that using just one line of code:
tell application "Finder" to reveal path:to:some:file
The file must actually exist for this to work, of course. You know a particular file/directory exists when it is presented in alias form (I.e. Macintosh HD:Users:billybob:Desktop:howToHack.pdf). Attempting to coerce a nonexistent file into an alias will result in an error. If you are 100% certain that the file exists and know exactly where it is, congratulations! You have one less thing to worry about. If your certainty level is anything less than 100%, use a try-catch block. They have saved my life on multiple occasions. That way, if you distribute your applications via the Internet like I do, your clients are not presented with undecipherable error messages.
An example of this is demonstrated below:
set theFile to "/Users/billybob/Desktop/folder/subfolder/subfolder2/subfolder3/fineByMe.mp3"
try
set theFile to (theFile) as alias
tell application "Finder" to reveal theFile
on error
display alert "The file " & quoted form of theFile & "does not exist."
-- The variable 'theFile' couldn't be coerced into an alias.
-- Therefore, 'theFile' still has a string value and it can be used in dialogs/alerts among other things.
end try
Is this more efficient or less time consuming than what you've written? I'm not particularly sure, to be honest. However, I have written many scripts that have included the reveal command on Mac OS X 10.5.8 (Leopard), Mac OS X 10.6.8 (Snow-Leopard), and Mac OS X 10.7.3 (Lion), and the results have been satisfying.
You have errors in your code.
You forgot a period after "exists" in the display alert line.
You cannot display a posix file. It must be converted to string. Apple doesn't have this optimization.
The exists command will always return false the way you've used it because you didn't provide a full file path. Although java and c++ allow abbreviated file paths, apple does not.
I cannot comment, so I was forced to put this as an answer instead.
Suppose you have an .EXE and you want to check if it has Command-Line Options. How can one know if the .EXE has this ability. In my case I know that Nir Sofers WebBrowserPassView.exe has the ability to start it via cmd.exe and WebBrowserPassView.exe /stext output.txt. But how can I find out if I don't know?
The easiest way would be to use use ProcessExplorer but it would still require some searching.
Make sure your exe is running and open ProcessExplorer.
In ProcessExplorer find the name of your binary file and double click it to show properties.
Click the Strings tab.
Search down the list of string found in the binary file. Most strings will be garbage so they can be ignored. Search for anything that might possibly resemble a command line switch.
Test this switch from the command line and see if it does anything.
Note that it might be your binary simply has no command line switches.
For reference here is the above steps applied to the Chrome executable. The command line switches accepted by Chrome can be seen in the list:
Invoke it from the shell, with an argument like /? or --help. Those are the usual help switches.
Sysinternals has another tool you could use, Strings.exe
Example:
strings.exe c:\windows\system32\wuauclt.exe > %temp%\wuauclt_strings.txt && %temp%\wuauclt_strings.txt
Just use IDA PRO (https://www.hex-rays.com/products/ida/index.shtml) to disassemble the file, and search for some known command line option (using Search...Text) - in that section you will then typically see all the command line options - for the program (LIB2NIST.exe) in the screenshot below, for example, it shows a documented command line option (/COM2TAG) but also some undocumented ones, like /L. Hope this helps?
Really this is an extension to Marcin's answer.
But you could also try passing "rubbish" arguments to see if you get any errors back. Getting any response from the executable directly in the shell will mean that it is likely looking at the arguments you're passing, with an error response being close to a guarantee that it is.
Failing that you might have to directly ask the publishers/creators/owners... sniffing the binaries yourself just seems like far too much work for an end-user.
Unless the writer of the executable has specifically provided a way for you to display a list of all the command line switches that it offers, then there is no way of doing this.
As Marcin suggests, the typical switches for displaying all of the options are either /? or /help (some applications might prefer the Unix-style syntax, -? and -help, respectively). But those are just a common convention.
If those don't work, you're out of luck. You'll need to check the documentation for the application, or perhaps try decompiling the executable (if you know what you're looking for).
This is what I get from console on Windows 10:
C:\>find /?
Searches for a text string in a file or files.
FIND [/V] [/C] [/N] [/I] [/OFF[LINE]] "string" [[drive:][path]filename[ ...]]
/V Displays all lines NOT containing the specified string.
/C Displays only the count of lines containing the string.
/N Displays line numbers with the displayed lines.
/I Ignores the case of characters when searching for the string.
/OFF[LINE] Do not skip files with offline attribute set.
"string" Specifies the text string to find.
[drive:][path]filename
Specifies a file or files to search.
If a path is not specified, FIND searches the text typed at the prompt
or piped from another command.
I am new to UNIX and when I was reading a book about UNIX, I came across following two problems that I didn't understand. I would really appreciate your help.
1) Look up the man page for the file command, and then use it on all files in the /dev directory. Can you group these files into two categories?
2) Run the tty command, and note the device name of your terminal. Now use this device name(/dev/pst/6) in the command cp /etc/passwd /dev/pts/6. what do you observe?
Fair question really... it's so easy for us to take so much for granted.
To read the manual page for the command called file, just type...
man file
...which will present a lot of information that will probably be quite confusing, but you'll get used to this stuff pretty quick if you keep at it. Crucially, file is a program that tries to categorise the files you ask it to. If you type...
file /dev/*
...that will do what the question asked, and invoke file with a list of the files in the /dev/ subdirectory. The list is actually prepared by the "shell" program that you're typing into, which then executes the file program and passes it the list. file then outputs some description of the files. On my computer, and where [SHELL-PROMPT] will be different on your computer, I typed file /dev/* and part of the output looked like:
[SHELL-PROMPT] file /dev/*
...lots of stuff...
/dev/cevt: character special (255/176)
/dev/console: character special (5/1)
/dev/core: symbolic link to `/proc/kcore'
/dev/cpqci: character special (10/209)
/dev/cpqhealth: directory
/dev/crom: character special (255/180)
...lots of stuff...
/dev/md8: block special (9/8)
/dev/md9: block special (9/9)
/dev/mem: character special (1/1)
/dev/mice: character special (13/63)
/dev/mouse0: character special (13/32)
/dev/mptctl: character special (10/220)
/dev/net: directory
/dev/nflog: character special (36/5)
/dev/null: character special (1/3)
/dev/parport0: character special (99/0)
...lots of stuff...
There's a filesystem entry for each directory/file combination (known as a path) in the left column, and file is describing the content in the right. Those descriptions may not make a lot of sense, but you can see that some patterns: some entries are "block special", others "character special", some are directory which implies you may find more files underneath (i.e. ls /dev/net/*). The numbers after "special" files are just operating system identifiers to differentiate the files mentioned. The import of this is that input and output from some devices connected to the computer is being made possible as if the device was a file in the filesystem. That "file" abstraction is being used as a general model for input and output. So, /dev/tty for example is tty - or terminal - device. Any data you try to read from there will actually be taken from the keyboard you're using to type into the shell (in the simple case), and anything you write there will become visible in the same terminal you're typing into. /dev/null is another interesting one: you can read and write from it, but it's an imaginary thing that never actually provides data (just indicates and End-of-File condition, and throws away any data written into it). You can keep reading from /dev/random and it will produce random values each time... good if you need random numbers or file content for encryption or some kind of statistical work.
2) Run the tty command, and note the
device name of your terminal. Now use
this device name(/dev/pst/6) in the
command cp /etc/passwd /dev/pts/6.
what do you observe?
By typing "tty" you can ask for the device representing your terminal...
[SHELL-PROMPT] tty
/dev/pts/11
But, I just said /dev/tty is another name for the same thing, so there's normally no need to use the "tty" program to find this more specific name. Still, if you create a couple terminal windows to your host, and type tty in each, you will see that each shell is connected to a different pseudo-terminal device. Still, each shell - and program run from the shell - can by default also refer to its own terminal input and output device as /dev/tty... it's a convenient context-sensitive name. The command...
cp /etc/passwd /dev/pts/6
...where you replace 6 with whatever your tty program really reported (e.g. 11 in my case), does the same thing as...
cp /etc/passwd /dev/tty
...it just reads the contents of the file /etc/passwd and writes them out on your screen. Now, the problem is that /etc/password looks like a lot of unintelligible junk to the average person - it's no wonder you couldn't make sense of what was happening. Try this instead...
echo "i said hello" > /tmp/hello.file
cp /tmp/hello.file /dev/tty
...and you'll see how to direct some specific, recognisable content into a new file (in this case putting it in the tmp "temporary" directory (the file will disappear when you reboot your PC), then copying that file content back to your screen.
(If you have logged on in two terminal windows, you can even go into one shell and copy the file to the /dev/pts/NN device reported by the other shell, effectively sending a message to the other window. You can even bypass the file and echo 'boo' > /dev/tty/NN. You'll only have permissions to do this if the same userid is logged into both windows.)