Stack Exchange
log in

cuonglm

 Discussion on answer by cuonglm: How …

Imported from a comment discussion on unix.stackexchange.com/q...
cuonglm
Jul 13, 2020 05:59
@ArchStanton Yes, remember that ++ return old value and increment one.
cuonglm
Jul 13, 2020 05:59
@ArchStanton No, ++ returns current seen[$0] and incrementing it immediately. That mean if current seen[$0] is 0, then ++ returns 0 and set seen[$0] to 1.
cuonglm
Jul 13, 2020 05:59
@Gilles: You can make the edit, I don't understand what did I confuse here. The doc and my analysis show that In expression evaluation, where the grammar is formally ambiguous, higher precedence operators shall be evaluated before lower precedence operators. Archemar's answer was wrong both in operator precedence and order of evaluation.
cuonglm
Jul 13, 2020 05:59
@Gilles: See my updated.
cuonglm
Jul 13, 2020 05:59
@Gilles: Read the doc please, ++ return a value, if you said ++ is evaluated after !, then the final result of expression in first time must be false. You can use awk 'BEGIN{a=0;print !(a++);} but not awk 'BEGIN{a=0;print (!a)++;}
cuonglm
Jul 13, 2020 05:59
@Gilles: The doc said Increment lvalue, returning the old value of lvalue as the value of the expression.. Can you give an example with your comment?
cuonglm
Jul 13, 2020 05:59
@G-Man:It's wrong. Read the documentation I gave in the Note. And your example is not equivalent with ++ operator behavior, since when it does not create any temp variable. Remember that ++ increment the value and return the old value. The result can be the same, but the order of parsing by awk is wrong in Archemar's answer.
cuonglm
Jul 13, 2020 05:59
@Archemar: Your answer indicate that ! is applied before ++.
 

 /dev/chat

General discussion for unix.stackexchange.com. If you have a q...
2
cuonglm
Nov 30, 2018 09:45
@terdon I still visit the website everyday, and I see you are more active than me :)
cuonglm
Nov 30, 2018 03:26
@terdon Thanks, I don't have much time to contribute to website as regularly as before
cuonglm
Apr 13, 2017 08:55
@Kusalananda I still confuse what the OP ask, if it's about ARG_MAX, then it should be marked as duplicated question. There're many questions about it IIRC
cuonglm
Apr 13, 2017 08:52
in-ulm.de/~mascheck/various/argmax
cuonglm
Apr 13, 2017 08:52
@Kusalananda and also ARG_MAX is not always available
cuonglm
Apr 13, 2017 08:43
@Kusalananda Did you read this part: "Also note (still on Linux 3.11) that the maximum size of a single argument or environment string is 128kiB, regardless of the size the stack."
cuonglm
Apr 9, 2017 17:29
@Gilles Ah ok, I figured it out
cuonglm
Apr 9, 2017 17:07
0
A: Extract unix compatible filepath with space from command output

cuonglmPOSIXLY: du -s "$HOME"/* | sort -rnk1 | LC_ALL=C sed -e "s,[^/]*\(/.*\),'\1',;q" Without -h, du result included plain number for size, so we can easily sort it without extra grep. Using sed to perform deletion at the first line only then quitting, we save a head invocation. With zsh: prin...

cuonglm
Apr 9, 2017 17:07
@Gilles Hi, do you have any information about this zsh weird behavior
cuonglm
Mar 30, 2017 16:08
@terdon No, I don't think so
cuonglm
Mar 30, 2017 16:04
@@terdon Ah, realize that the awk on OSX is Brian Kernighan's one
cuonglm
Mar 30, 2017 15:50
I tried with nawk, gawk and the one found on OSX, all does the same thing
cuonglm
Mar 30, 2017 15:45
@terdon it's interesting that set awk -F ' ' does not change anything, the blank characters still be used to split fields
cuonglm
Mar 29, 2017 15:05
because it wraps in another zsh -c
cuonglm
Mar 29, 2017 14:57
zsh -c finish and quit immediately
cuonglm
Mar 29, 2017 14:56
exec replace the shell with the new command zsh -c
cuonglm
Mar 29, 2017 14:43
0
Q: Why zsh precommand modifiers stop accepting arguments if quoted?

cuonglmzsh has precommand modifiers, which precede a command to alter how command is interpreted. Some of them are command and exec. $ zsh -c 'exec -a foo zsh -c "print -- \$0"' foo $ zsh -c 'command -v ls' /bin/ls But they stopped accepting arguments if quoted: $ zsh -c '\exec -a foo zsh -c "print ...

zsh
cuonglm
Mar 29, 2017 14:43
Does anyone face this problem in zsh
 

 Discussion between Wildcard and cuonglm

Imported from a comment discussion on unix.stackexchange.com/q...
cuonglm
Nov 2, 2016 07:42
No problem :)
cuonglm
Nov 2, 2016 07:41
yep, mee too :+1:
cuonglm
Nov 2, 2016 07:39
their issues and discussions are very useful
cuonglm
Nov 2, 2016 07:39
Stephane, Schily, Thomas Dickey ...
cuonglm
Nov 2, 2016 07:39
and it's interesting that you will see many reporters who are in U&L
cuonglm
Nov 2, 2016 07:38
I don't remember all, but I only know geoffclare and ajosey often accept and approve isses
cuonglm
Nov 2, 2016 07:37
opengroup.org/austin/faq.html
cuonglm
Nov 2, 2016 07:37
There's FAQ for those questions
cuonglm
Nov 2, 2016 07:34
yes, that's it
cuonglm
Nov 2, 2016 07:34
@Wildcard AFAIK, no. You must search the austingroup bug site, with tag filter issue 8
cuonglm
Nov 2, 2016 07:32
let me check
cuonglm
Nov 2, 2016 07:32
Anyway, I remember the question how austinbug group issue process was asked somewhere
cuonglm
Nov 2, 2016 07:31
next will be 8
cuonglm
Nov 2, 2016 07:30
current POSIX issue is 7
cuonglm
Nov 2, 2016 07:30
because new version isn't there
cuonglm
Nov 2, 2016 07:30
yes, it's accepted to be included in new version, but not yet
cuonglm
Nov 2, 2016 07:26
also, its status is resolved, not approved :D
cuonglm
Nov 2, 2016 07:25
sorry, it doesn't, as it's tagged issue 8
cuonglm
Nov 2, 2016 07:25
Ah
cuonglm
Nov 2, 2016 07:24
I think it does
cuonglm
Nov 2, 2016 07:18
The only sensible explanation is a whole command group ({ to the matching }). As in {...;} cannot be followed by ;, but then again all implementations I tested including Unix V7 allow:

sed '{=;};{=;}'
cuonglm
Nov 2, 2016 07:18
and his comment
cuonglm
Nov 2, 2016 07:18
@Wildcard See this issue by Stephane austingroupbugs.net/view.php?id=944
cuonglm
Nov 2, 2016 07:14
I think they made the change after that issue accepted