I tried to add this line to a key in registry
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"-ExecutionPolicy Bypass -windowstyle hidden -noexit -file "%1"
as you see the value that i want to add contains """" and % and -
So how can i do it please
i know with Registry.SetValue as here
Registry.SetValue(#"HKEY_CLASSES_ROOT\Microsoft.PowerShellScript.1\Shell\Open\Command", "Default", #""C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"-ExecutionPolicy Bypass -windowstyle hidden -noexit -file "%1"");
but errors popup every time i putted # at the beginning
but didnt work also
this key will allow me if i edited it to run powershell script by double click on it
any ideas ?..thx
The syntax highlighting shows the issue. The third parameter is
""C:\Windows\System32\WindowsPowerShell...
Thus, the compiler sees an empty string "" and unexpected C:\Windows\System32\WindowsPowerShell...
As resolution, use string literal properly
#"C:\Windows\System32\WindowsPowerShell...
Just put another " to escape each "
Registry.SetValue(#"HKEY_CLASSES_ROOT\Microsoft.PowerShellScript.1\Shell\Open\Command", "Default", #"""C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe""-ExecutionPolicy Bypass -windowstyle hidden -noexit -file ""%1""");
Related
The recommended way to store secrets (like API keys and passwords) during development of an ASP.NET core 3 application is to use user secrets. While this approach works nicely I do have a multiline string which contains an RSA key. The key is copied from a provided .pem file.
Is there any easy way to store the key in secrets.json?
The problem seems to be that json does not support multiline strings. Thus simply copying the key into the file does not work. Workarounds like using an array for the different lines of the key does not play nicely with the Configuration class and binding retrieved secrets to an Options-class.
I have figured out that once I convert the key into a single line string it works. However, the need for a separate tool to convert the key from multiline to single line, seems to me too complex.
By the way, I do need this for building a GitHub-App.
There's nothing stopping you from using a multi-line string with user secrets. You can pass one directly to dotnet user-secrets
For example, some Powershell using a here-string:
$multiVal = #"
Your
Multi-line
Text
"#
dotnet user-secrets set "YourKeyName" "$multiVal"
Or with embedded new-line character `n:
dotnet user-secrets "YourKeyName" "Your`nMulti-line`nValue"
Or you could read in an entire text-based file:
$fileName = "/path/to/file"
$multiVal = Get-Content $fileName -Raw
dotnet user-secrets set "YourKeyName" "$multiVal"
A JSON string property also allows "multi-line" text, just not in the way you're thinking. The literal characters \ and n together inside of a string property will be deserialized as a new-line. For example, the following JSON has a string property with a multi-line value:
{
"YourKeyName": "Your\nMulti-line\nText"
}
You can achieve this in a variety of ways, for example doing a manual find-and-replace or with tools like Notepad++. You could also use some Powershell once again:
$inputFile = "/path/to/file"
$multiVal = Get-Content $inputFile -Raw
$obj = [pscustomobject]#{
YourKeyName = $multiVal
}
$outputFile = "/path/to/secrets.json"
$obj | ConvertTo-Json -Depth 50 | Out-File -FilePath $outputFile
Edit: you mentioned one of the parameters is not working in the final example. It's possible you are somehow running an older version of powershell (pre 3.0). You can try this instead:
$inputFile = "/path/to/file"
# no -Raw flag
$multiVal = (Get-Content $inputFile | Out-String)
# or alternatively
$multiVal = [System.IO.File]::ReadAllText($inputFile)
$obj = [pscustomobject]#{
YourKeyName = $multiVal
}
$outputFile = "/path/to/secrets.json"
# use redirection instead of Out-File
($obj | ConvertTo-Json -Depth 50) > $outputFile
Now with respect to RSA keys, according to this answer and its comments while the RSA spec calls for line breaks within the base-64 encoded payload it's possible that implementations may allow non-conformance. This means that depending on how you're using it, you might be able to get away with stripping out the new-lines entirely. You'd have to try it out to know for sure.
Edit: It turns out that dotnet user-secrets has/had a known bug where values cannot have a leading -. It's fixed now but I think only for 5.0+. I found that a leading space works and I would think that the RSA provider shouldn't balk at that. The following should work:
dotnet user-secrets set "PKeyPowerShell" " $multiVal"
I develop an application with command line parameters and use it in cmd shell and powershell. There it is obvious that the arguments are received differently in main() of my application.
static void Main(string[] args)
{
// In cmd shell: args[0] == "-ipaddress=127.0.0.1"
// In powershell: args[0] == "-ipaddress=127"
// and args[1] == ".0.0.1"
}
Example:
myApp.exe -ipaddress=127.0.0.1
In my C# application the arguments are interpreted differently depending on the shell I start the app in.
In cmd shell: arg[0]=-ipaddress=127.0.0.1
In powershell: arg[0]=-ipaddress=127 and arg[1]=.0.0.1
What is best practice here?
Should I join all args[] and parse the arguments in my application?
Should I rely on the shell's parser?
I would abandon cmd shell support completely and just created proper PowerShell cmdlet. Writing a Windows PowerShell Cmdlet. But I don't know your exact requirements.
In general calling executable from cmd and PowerShell should work same way. For example line, "> ping -n 3 google.com" just works fine no matter where you put it.
tl;dr:
When calling from PowerShell, enclose the entire argument in '...' (single quotes) to ensure that it is passed as-is:
myApp.exe '-ipaddress=127.0.0.1'
You've run into a parsing bug[1]
where PowerShell breaks an unquoted argument that starts with - in two at the first .
The following simplified example demonstrates that:
# Helper function that echoes all arguments.
function Out-Argument { $i = 0; $Args | % { 'arg[{0}]: {1}' -f ($i++), $_ }}
# Pass an unquoted argument that starts with "-" and has an embedded "."
Out-Argument -foo=bar.baz
The above yields:
arg[0]: -foo=bar
arg[1]: .baz
[1] The presumptive bug is present as of Windows PowerShell v5.1 / PowerShell Core v6.0.1 and has been reported on GitHub.
A PSv2 variation of the bug affects . when enclosed in "..." in the interior of the argument - see this answer of mine.
I want to create subject certificate name which contains "," like the image
Example
but always fails because "," is used to separated the contain of -n parameter like
“CA=CARoot,O=My Organization,OU=Dev,C=Denmark”
Anyone know how to add "," into certificate name? Much appreciate for your helping
In a Windows Command Prompt you can use a triple-double-quote to make a literal double quote in a quoted argument (from https://stackoverflow.com/a/15262019/6535399).
The X500 name parser uses commas as separators unless it's in a quoted string. So you need the -n value to be interpreted as OU="Hey, there", ....
So, you can do something like
> makecert.exe (etc) -n "OU="""Hey, there""", O=Hmm, CN="""Hello, Nurse!""""
or, to make the what-looks-like-a-quadruple-quote go away:
> makecert.exe (etc) -n "OU="""Hey, there""", O=Hmm, CN="""Hello, Nurse!""", C=US"
I tried your solution but It did not work, my command:
MakeCert.exe -r -pe -n "OU=(c) 2006 thawte Inc."""Hey, there""" - For authorized use only" -sv "c:\PlaneteersLtd_certificate\XIAMEN_IPRT_TECHNOLOGYLtd1.pvk" -len 2048 "c:\PlaneteersLtd_certificate\XIAMEN_IPRT_TECHNOLOGYLtd1.cer"
When I remove """Hey, there""", it create the cert file successfully
Example
I've created a .NET console application that gets some command line arguments.
When I pass args with white spaces, I use quotes to embrace these arguments so that they are not splitted by cmd:
C:\MyAppDir> MyApp argument1 "argument 2" "the third argument"
If I execute the app in Windows XP it works fine: it gets 3 arguments:
argument1
argument 2
the third argument
However, if i execute it in Windows Server 2008 it seems to ignore quotes: it gets 6 arguments:
argument1
"argument
2"
"the
third
argument"
Any ideas why?
NOTE: I printed arguments just when Main starts execution using this code:
Console.WriteLine("Command line arguments:");
foreach (string arg in args)
{
Console.WriteLine("# " + arg);
}
Make sure the character you are typing is indeed the double quote ".
Maybe it's a character that looks like it.
I know my Greek language settings produce a " but it's not read that way.
Please Try it.
C:\MyAppDir> MyApp argument1 \"argument 2\" \"the third argument\"
You can try, put each arguments between Quota"" and in the paths put double backslash for example like that:
generadorPlantillasPDF.exe "C:\GDI\desarrollos\celula canales\proyectos\Progreso\curso xml\" generadorprogreso.xml C:\Temp\ BVI "C:\GDI\desarrollos\celula canales\proyectos\Progreso\plantilla\" "C:\GDI\desarrollos\celula canales\proyectos\Progreso\" "Formulario Progreso Version 2.0.docx" C:\Temp\
I'm trying to run a command in cmd using C# and am having some difficulties. I'd like to be able to write the command to the cmd console so I can see what it's trying to run (I think there's some issue with the quotes or something, so if I could see the actual string in the command line, I'd be able to see exactly what the problem is). My code looks like this:
var processStartInfo = new ProcessStartInfo("cmd", "/c"+commandString);
processStartInfo.CreateNoWindow = true;
Process.Start(processStartInfo);
So basically, I just want to see the string commandString written in the console. Any help would be greatly greatly appreciated.
string CommandLineString = #"""C:\Program Files\Microsoft SQL Server\100\Tools\Binn\bcp.exe"" ""SELECT * FROM table where date >= '2009-01-01'"" queryout ""C:\Data\data.dat"" -S DBSW0323 -d CMS -n -T";
In this case, the problem is probably just your lack of a space after "/c".
var processStartInfo = new ProcessStartInfo("cmd", "/c " + commandString);
As for viewing in a command window, instead, you will probably be better off inspecting the Arguments property of your processStartInfo instance.
EDIT
Taking into account the command line details you posted, I believe this is what your issue is. Check out the following from cmd help:
If /C or /K is specified, then the remainder of the command line after
the switch is processed as a command line, where the following logic is
used to process quote (") characters:
If all of the following conditions are met, then quote characters
on the command line are preserved:
no /S switch
exactly two quote characters
no special characters between the two quote characters,
where special is one of: &<>()#^|
there are one or more whitespace characters between the
the two quote characters
the string between the two quote characters is the name
of an executable file.
Since you are using /c, you have quote and special char issues still. Try wrapping your entire commandString in a set of quotes.
Take this simple example for instance (creating temp.txt manually of course):
string commandString = #"""C:\WINDOWS\Notepad.exe"" ""C:\temp.txt""";
var processStartInfo = new ProcessStartInfo("cmd", "/c " + commandString);
The command line to be executed will be: /c "C:\WINDOWS\Notepad.exe" "C:\temp.txt", but this will fail since "C:\temp.txt" is not an executable.
If you wrap the whole thing in one last set of quotes, you should see the intended result:
string commandString = #"""""C:\WINDOWS\Notepad.exe"" ""C:\temp.txt""""";
var processStartInfo = new ProcessStartInfo("cmd", "/c " + commandString);
Resulting in a command line of: /c ""C:\WINDOWS\Notepad.exe" "C:\temp.txt"" and ultimately opening notepad with your test file.
That string is not "written" to the console, it's part of the argument list for a program you launch (which in this case happens to be cmd.exe). Since the console created is owned by that program, unless it wants to print its arguments for its own reasons (which it won't) this is not directly doable.
If you simply want to debug then why not inspect the value of commandString, or write it out into a log file?
If you absolutely need the command line to be displayed in the console then you could resort to hacks (run another intermediate program that prints the command line and then calls cmd.exe with it), but unless there is some other good reason to use this approach I would not recommend it.