Can someone explain this result to me? I've wasted a lot of time over the years trying to master PowerShell's syntax for calling commands, but this...I can't even make a guess how to get this result from the input.
PS C:\Users\P> & echoargs " ""1"" 2 3 ""4 5 6"" 7 8 9"
Arg 0 is < 1 2 3 4>
Arg 1 is <5>
Arg 2 is <6 7 8 9>
Bueller?
The doubled-up doubles quotes inside a double-quoted string is a way to insert a double quote. The updated version of echoargs.exe shows this a bit more clearly as it shows you the command line used to invoke the exe:
PS> echoargs " ""1"" 2 3 ""4 5 6"" 7 8 9"
Arg 0 is < 1 2 3 4>
Arg 1 is <5>
Arg 2 is <6 7 8 9>
Command line:
"C:\...\Modules\Pscx\Apps\EchoArgs.exe" " "1" 2 3 "4 5 6" 7 8 9"
If you take that command line (after it has been parsed by PowerShell) you get the same result in CMD.exe:
CMD> EchoArgs.exe " "1" 2 3 "4 5 6" 7 8 9"
Arg 0 is < 1 2 3 4>
Arg 1 is <5>
Arg 2 is <6 7 8 9>
Command line:
C:\...\Modules\Pscx\Apps\EchoArgs.exe " "1" 2 3 "4 5 6" 7 8 9"
As to why .NET or the C++ startup code parses the command line that way, I'm not entirely sure. This MSDN topic covers it a bit and if you look at the examples at the bottom of the topic, you will see some equally weird parsing behavior e.g. a\\\b d"e f"g h gives a\\\b, de fg and h.
Note that Powershell is known for some heavy bugs when it comes to passing arguments to applications and quoting the said arguments - http://connect.microsoft.com/PowerShell/feedback/details/376207/executing-commands-which-require-quotes-and-variables-is-practically-impossible
This is how I understand how it is being (mis)parsed:
The string is " ""1"" 2 3 ""4 5 6"" 7 8 9"
Because of the bug the double double quotes, which become literal double quote, never make it.
The string would be like " "1" 2 3 "4 5 6" 7 8 9"
So <space>1 2 3 4 becomes an argument because it the first section with matching quotes and 4 occurs before the next space. Then space, and hence 5 becomes second argument. Then space, so the next part will be a separate argument. Here again, the same rule as the first argument, except that 6 occurs before quote and without a space and hence 6 7 8 9 becomes the next argument.
Bottomline - Powershell argument passing to external applications is pretty messed up.
Related
I'm trying to understand this:
100+\ 1 2 3
101 103 106
Which works fine.
Question 1:
When I wrap this in brackets, I get an error I wasn't expecting:
(100+\) 1 2 3
'Cannot write to handle 100. OS reports: Bad file descriptor
What am I doing wrong here? It doesn't look like I'm writing a file to me.
Question 2:
Given the +[1;2] = 3, I believe this:
+[100;]\ 1 2 3
'
[0] +[100;]\ 1 2 3
(or perhaps +[;100]\ 1 2 3) should also work with projection, but it doesn't. What am I doing wrong here?
Question 1:
Use parse to determine order of execution
q)show pt:parse "(100+\\)1 2 3"; // need to escape \
((\;+);100)
1 2 3
q)eval each pt // should be clearer now
100
1 2 3
q)
q)value eval each pt // attempting to apply 100 to list which cannot be done
'Cannot write to handle 100. OS reports: Bad file descriptor
[0] value eval each pt
^
Question 2:
The projection is unary & is applied to the entire right argument. With unary application, evaluations will (attempt to) continue until convergence - https://code.kx.com/q/ref/accumulators/#unary-values
q)(neg\)1 2 3
1 2 3
-1 -2 -3
q)+[100]\[1 2 3]
'wsfull
m 0 68157440
Question 1
When an iterator (here \) is applied postfix (as is usual) to a function (here +) it derives a function (here +\) that is both variadic (as per #mturkington) and has infix syntax. You can apply it as a unary or as a binary. Your example 100+\1 2 3 applies it as a binary.
The parser needs a clue if you want to apply +\ as a unary. You can apply any function using bracket notation. Or you can parenthesise it: (+\) has noun syntax, as does the list (+;-;*;%). You can apply or index a noun with prefix syntax.
q)100+\1 2 3 / binary application, infix syntax
101 103 106
q)+\[100;1 2 3] / binary application, bracket syntax
101 103 106
q)+\[1 2 3] / unary application, bracket syntax
1 3 6
q)(+\)1 2 3 / unary application, prefix syntax
1 3 6
Question 2
You don’t say what result you expect from using the projection. I’ll assume you’re exploring a different way of getting the same result as in Q1.
The key issue here is that the projection of binary Add on 100 is a unary +[;100] (or +[100] or just 100+), and the accumulators \ and / applied to a unary are the Converge, Do and While iterators.
None of these gives you the Q1 result. For unary f, the derived function f\ just keeps applying f successively.
q)5 +[100]\ 1 2 3 / do 100+ five times
1 2 3
101 102 103
201 202 203
301 302 303
401 402 403
501 502 503
In this case, +\ is the underlying code for the sums keyword. This is one of several keywords that are known as variadic because their rank is not fixed. When you try (100+\) 1 2 3, kdb is actually applying the equivalent of sums to your input list, then trying to write that to handle 100, which of course doesn't exist. So that's why you get the error you get.
As for the syntax in Question 2, the following should work (adapted from this page on the variadic syntax)
q)+\[100;1 2 3]
101 103 106
I noticed a difference between PowerShell 4 and PowerShell 5.
Lets consider the following PowerShell script:
. SomeProgram.exe "something=""Hello World!"""
Arguments seen by 'SomeProgram.exe' with PowerShell 4 (and maybe
less):
arg 0: something=Hello
arg 1: World!
Arguments seen by 'SomeProgram.exe' with PowerShell 5:
arg 0: something=Hello World!
Please note that this difference only occurs when the argument contains some text before the double quote:
"sometext""Hello World!""" 🡒 KO
but
"""Hello World!""" 🡒 OK
Conclusion:
PowerShell 4 seems to have a bug when it comes to parsing an argument in form of:
ATextWithoutSpace"A Text with space"
PowerShell 5 strips double quotes and considers the whole string as a single argument (like it should be).
PowerShell 4 strips double quotes but makes several arguments by splitting the string with spaces.
Is there a way to get the same behavior between PowerShell 4 et PowerShell 4?
When I run my Forms code I have different objects that are added to the Form (buttons, labels, etc) I attache the objects to the form by using the command $Form1.Controls.Add([ObjectType]).
My question is, when I run my code I get an instant sequence of numbers in my console and output dialogue box of:
0 1 2 3 4 5 6 7 8 9 0 1 2
When after I click Submit button the string "OK" is added to the numbers shown above
0 1 2 3 4 5 6 7 8 9 0 1 2 OK
Why is this happening and how can I remove these or atleast omit them from displaying.
The OK displays once the Submit button is pressed.
OK
Some actions like .Add() are producing output. To prevent this, pipe the output into the [void] by adding | Out-Null at the end of the line or [void] directly infront of the variable that is used, like:
$foo.SomethingThatGeneratesOutput() | Out-Null
or
[void]$foo = SomethingThatGeneratesOutput
As T-Me has stated, to prevent output being generated when executing methods as you are use [Void].
[Void]$Form1.Controls.Add([ObjectType])
If your code is still returning unwanted data, open the script in PowerShell ISE, and execute the script line by line (select the line and press F8). This will help you determine which line of code is generating output still.
This question already has answers here:
What does the “##…##” meta line with at signs in svn diff or git diff mean?
(3 answers)
Closed 7 years ago.
Every time I run git diff, for each single changes I made, I get some sort of header with numbers, for example:
## -169,14 +167,12 ## function Browser(window, document, body, XHR, $log) {.....
I wonder what does the four numbers mean? I guess -169 means that this particular line of code that follows was originally in line 169 but now is in 167? And what do 14 and 12 mean?
This header is called set of change, or hunk. Each hunk starts with a line that contains, enclosed in ##, the line or line range from,no-of-lines in the file before (with a -) and after (with a +) the changes. After that come the lines from the file. Lines starting with a - are deleted, lines starting with a + are added. Each line modified by the patch is surrounded with 3 lines of context before and after.
An addition looks like this:
## -75,6 +103,8 ##
foo
bar
baz
+line1
+line2
more context
and more
and still context
That means, in the original file before line 78 (= 75 + 3 lines of context) add two lines. These will be lines 106 (= 103 + 3 lines of context) through 107 after all changes.
Note the difference in from numbers (-75 vs +103), this means that there were other changes in this file before this particular hunk, that added 28 (103 - 75) lines of code.
A deletion looks like this:
## -75,7 +75,6 ##
foo
bar
baz
-line1
more context
and more
and still context
That means, delete line 78 (= 75 + 3 lines of context) in the original file. The unchanged context will be on lines 75 to 80 after all changes.
Note that from numbers in this hunk are equal (-75 and +75), this means that either there were no changes before this hunk, or amount of added and deleted lines in previous changes are the same.
Finally, a change looks like this:
## -70,7 +70,7 ##
foo
bar
baz
-red
+blue
more context
and more
still context
That means, change line 73 (= 70 + 3 lines of context) in the file before all changes, which contains red to blue. The changed line is also line 73 (= 70 + 3 lines of context) in the file after all changes.
I wonder what does the four numbers mean?
Let's analyze a simple example
The format is basically the same the diff -u unified diff.
We start with numbers from 1 to 16 and remove 2, 3, 14 and 15:
diff -u <(seq 16) <(seq 16 | grep -Ev '^(2|3|14|15)$')
Output:
## -1,6 +1,4 ##
1
-2
-3
4
5
6
## -11,6 +9,4 ##
11
12
13
-14
-15
16
## -1,6 +1,4 ## means:
-1,6 means that this piece of the first file starts at line 1 and shows a total of 6 lines. Therefore it shows lines 1 to 6.
1
2
3
4
5
6
- means "old", as we usually invoke it as diff -u old new.
+1,4 means that this piece of the second file starts at line 1 and shows a total of 4 lines. Therefore it shows lines 1 to 4.
+ means "new".
We only have 4 lines instead of 6 because 2 lines were removed! The new hunk is just:
1
4
5
6
## -11,6 +9,4 ## for the second hunk is analogous:
on the old file, we have 6 lines, starting at line 11 of the old file:
11
12
13
14
15
16
on the new file, we have 4 lines, starting at line 9 of the new file:
11
12
13
16
Note that line 11 is the 9th line of the new file because we have already removed 2 lines on the previous hunk: 2 and 3.
Summary:
Assume git diff will output [0-3] lines of context [before/after] [first/last] changes
## -[original file's number of first line displayed],[context lines + removed lines] +[changed file's number of first line displayed],[context lines + added lines] ##
I have a big text file and the data in it are in 5 columns, but I need just the first and the last column of that.
It will take many days and probably with mistake if I want to enter the data of this two column one-by-one from here to another file.
Is there a fast way to do this?
For example:
1 1.0000000000000000 0.0000000000 S {0}
2 1.5000000000000000 0.3010299957 C {2}
3 1.7500000000000000 0.6020599913 S {0,2}
4 2.0000000000000000 0.7781512504 C {3}
5 2.3333333333333333 1.0791812460 C {3,2}
6 2.5000000000000000 1.3802112417 S {3,0,2}
7 2.5277777777777778 1.5563025008 S {0,3}
8 2.5833333333333333 1.6812412374 S {3,0,0,2}
9 2.8000000000000000 1.7781512504 C {5,2}
10 3.0000000000000000 2.0791812460 C {5,0,2}
I need the first column (numbering) and the last inside { }.
ALT + Left Mouse Click puts you in Column Mode Select. It's quite an useful shortcut that may help you.
in Notepad++, you can use regular expression to do replacement:
the regex for find and replace is:
^( +\d+).+\{([\d,]+)\}$
\1 \2
then can change the:
1 1.0000000000000000 0.0000000000 S {0}
2 1.5000000000000000 0.3010299957 C {2}
3 1.7500000000000000 0.6020599913 S {0,2}
4 2.0000000000000000 0.7781512504 C {3}
5 2.3333333333333333 1.0791812460 C {3,2}
6 2.5000000000000000 1.3802112417 S {3,0,2}
7 2.5277777777777778 1.5563025008 S {0,3}
8 2.5833333333333333 1.6812412374 S {3,0,0,2}
9 2.8000000000000000 1.7781512504 C {5,2}
10 3.0000000000000000 2.0791812460 C {5,0,2}
to:
1 0
2 2
3 0,2
4 3
5 3,2
6 3,0,2
7 0,3
8 3,0,0,2
9 5,2
10 5,0,2
if not want the leading space, then use:
^( +\d+).+\{([\d,]+)\}$
\1 \2
will change to:
1 0
2 2
3 0,2
4 3
5 3,2
6 3,0,2
7 0,3
8 3,0,0,2
9 5,2
10 5,0,2
You should use awk or gawk which is available on windows platform also. Use gawk "{print $1,$5}" inpfile > outfile. I copied your file named it 'one'. You can see the output which consists of 1st and 5th column of your file.
>gawk "{print $1, $5}" one
1 {0}
2 {2}
3 {0,2}
4 {3}
5 {3,2}
6 {3,0,2}
7 {0,3}
8 {3,0,0,2}
9 {5,2}
10 {5,0,2}
You can import it into Excel and manipulate it there.
If you are using .NET, FileHelpers may save you a lot of time. From your post we can't tell what technology you are hoping to use to accomplish this.
Ultraedit has a tool for selecting columns and opens large files (I tried a 900 Mb file on a 2008 desktop and it opened in 3 minutes). I think it has a demo version fully operational.
Excel could work if you do not have too many rows.
Cheers,
One more way is to copy the data to MS word file.
Then use
{Alt + left mouse click}
Then you can drag on the selected column and you can see only a single column is selected.
Copy and paste wherever you want.
There is only one way to convolve ungodly amounts of data. That is with the command prompt.
$cat text.txt | sed 's/{.*,//;s/ */ /g;s/[{}]//g' | awk '{print $1","$5}' > clean_text.csv
This 15 second fix is not available in Windows OS. It will take you less time to download and install Linux on that old dead computer in your closet than it will to get your data in and out of Excel.
Happy coding!