The following script loses the values of arg1 and arg2.
Save this script as "c:\testing.txt"
.echo first argument is: ${$arg1}
.echo second argument is: ${$arg2}
~*e .echo thread ; !for_each_frame .echo frame
.echo first argument is: ${$arg1}
.echo second argument is: ${$arg2}
Run this script using:
$$a<"c:\testing.txt" alpha bravo
The first two print statements (before the loop) work the last two (after the loop) don't:
Before the loop:
0:027> $$a<"c:\testing.txt" alpha bravo
0:027> .echo first argument is: ${$arg1}
first argument is: alpha
0:027> .echo second argument is: ${$arg2}
second argument is: bravo
After the loop:
0:027> .echo first argument is: ${$arg1}
first argument is: ${$arg1}
0:027> .echo second argument is: ${$arg2}
second argument is: ${$arg2}
Any ideas on why !for_each_frame does this? If I take out that part and just do the looping through threads I don't lose the value of arg1 and arg2.
I tried storing arg1 and arg2 in aliases - but that didn't help. Is there any way I can store these argument values before the !for_each_frame so I don't lose them?
I'm using Microsoft (R) Windows Debugger Version 6.2.9200.20512 AMD64
I got this from: http://msdn.microsoft.com/en-US/windows/hardware/hh852363
This script worked in: Microsoft (R) Windows Debugger Version 6.12.0002.633 AMD64
Related
I'm trying to create a fish function with named argument contains a wildcard *. But the output between the function I made and the plain command are different.
Here's my function:
function ls-wildcard -a arg
ls $arg
end
and here's the result when I tried to execute it
$ ls-wildcard path/*.foo
bar1.foo
The output shows only 1 file when there should be 2 of them. But the plain ls works like a charm.
$ ls path/*.foo
bar1.foo bar2.foo
Am I missing something?
Edit:
After I tried some different expressions, the behavior of the function seems to terminate itself after the first matched. any way to fix it?
The wildcard is expanded before the function is run.
Your function uses a named argument, which is one argument.
So it is equivalent to this:
function ls-wildcard
ls $argv[1]
end
ls-wildcard path/*.foo
# runs `ls-wildcard` like
ls-wildcard path/bar1.foo path/bar2.foo
and then your function throws away the second argument.
The simplest fix is to just use $argv:
function ls-wildcard
ls $argv
end
which will forward all arguments to ls.
I have a powershell build step in TeamCity:
param ([string] $a)
Write-Host "`$a is '$a'."
and in this step I set parameter $a as -a "%TestParam%" or as "-a %TestParam%", where TestParam has two lines abra and cadabra.
When I run the build I get the following output:
[Step 1/10] PowerShell arguments: -NoProfile, NonInteractive, -ExecutionPolicy, ByPass, -File, C:\buildAgent\temp\buildTmp\powershell1746295357460795314.ps1, -a, "abra, cadabra"
[Step 1/10] $a is 'abra cadabra'.
The only question I have: What on earth happened to the comma? Why has it disappeared?
If I do not use quotes at all (-a %TestParam%), then TeamCity passes each line as a separate parameter and I see $a is 'abra'..
Mathias R. Jessen's answer explains PowerShell's parsing of ,-separated tokens as arguments [his answer has since been deleted, but I hope it will be undeleted], but that doesn't apply in the case at hand, because any arguments passed to PowerShell's CLI via -File are not subject to PowerShell's command-line parsing - instead, such arguments are treated as literals.
That is, if the command line invoked by TeamCity truly were the following:
powershell ... -File C:\...ps1 -a "abra, cadabra"
then parameter variable $a would receive value abra, cadabra, as expected.
In other words: What is actually being passed in your case must be abra cadabra, not
abra, cadabra, so you need to revise the value of %TestParam% to ensure that it actually contains the desired comma.
As for why the log of the command invoked suggests that there is a , present in what you're passing:
I can only speculate, based on your own guess:
I suspect TeamCity of being a liar, showing lines joined with comma, but passing them without it.
Perhaps TeamCity, when logging invocation of a command line, naively breaks that command line into tokens by whitespace only, without considering quoting, and then presents them as a ,-separated list.
If this is indeed the case, then argument "abra cadabra" - without comma - would be logged as
"abra, cadabra", which would explain the confusion.
How can we pass arguments to scala script like how we pass arguments to a shell script.
Much like you have to set an environment variable to pass JVM arguments, you can set an environment variable for your arguments.
set MYVARS=arg1 arg2 arg3
Then in your scala script:
val args = sys.env("MYVARS").split(" ").map(_.trim).toList
args.foreach { println }
Declare your script with bash command on top like this
Test.scala
#!/bin/sh
exec scala "$0" "$#"
!#
object Test {
def main(args: Array[String]): Unit = {
println(s"args: ${args.mkString("[", ", ", "]")}")
}
}
It works
[Desktop] ./Test.scala "scala is awesome" "java8 has lambdas"
args: [scala is awesome, java8 has lambdas]
More info regarding $0 and $#
0 Expands to the name of the shell or shell script.
This is set at shell initialization. If bash is
invoked with a file of commands, $0 is set to
the name of that file. If bash is started with
the -c option, then $0 is set to the first argument
after the string to be executed, if one is present.
Otherwise, it is set to the file name used to invoke
bash, as given by argument zero.
# Expands to the positional parameters, starting from
one. When the expansion occurs within double quotes, each
parameter expands to a separate word. That is, "$#" is
equivalent to "$1", "$2" ... If the double-quoted
expansion occurs within a word, the expansion of the first
parameter is joined with the beginning part of the original
word, and the expansion of the last parameter is joined
with the last part of the original word. When there are no
positional parameters, "$#" and $# expand to nothing
(i.e., they are removed).
for more info visit: Command line args for Scala scripts
I have a script foo.cmd:
echo %1 %2
In PowerShell I run:
foo.cmd "a,b" "c"
Expected output: a,b c
Actual output: a b
Why?
The double quotes are removed after PowerShell parsed the command line and passes it to CMD for execution, so CMD actually sees a statement
foo.cmd a,b c
Since the comma is one of CMD's delimiter characters that statement is equivalent to
foo.cmd a b c
To avoid this behavior you need to ensure that the double quotes are preserved when passing the arguments to CMD. There are several ways to achieve this. For instance, you could put the double quoted arguments in single qoutes:
foo.cmd '"a,b"' "c"
and change the positional parameters in the batch script to %~1, %~2 so that CMD removes the double quotes from the arguments.
If you have PowerShell v3 or newer you can use the "magic parameter" --% to avoid the nested quotes:
foo.cmd --% "a,b" "c"
You still need %~1 and %~2 in the batch script, though.
I have a DOS batch-file MYDOS.BAT containing:
My C-application (myApp.exe) reading an input-file (inputFile) from the DOS-command line
myApp.exe analyses inputFile and exits/returns with a code=N
How can I pass value N into my MATLAB script?
E.g: MYDOS.BAT is run by DOS>MYDOS inputFile and contains the following lines:
myApp %1
echo %ERRORLEVEL%
set samplerate=%ERRORLEVEL%
echo %samplerate%
...
C:/... matlab mymatlab.m ...
HOW CAN I THEN PASS the value %samplerate% into my mymatlab.m script?
You can use the system command to use DOS commands in Matlab. Use doc system to see the documentation.
System can have 2 outputs. The first one is a status, which will tell you if the operation succeeded. The second one is the output to the command prompt. You can parse this to get your value. You could use the following code as a guide for your situation:
[status,cmdout]=system('MYDOS.bat');
cmdout will contain the string that you are echoing to the command prompt.