Hacker News new | past | comments | ask | show | jobs | submit login

eh, common.sh is a lot more complicated than it could be. example:

    write_hex() {
     hex="$1"
     echo "$hex" | sed -e 's/../&\n/' | while read -r hexbyte; do
      printf "\\x$hexbyte"
     done
    }
you can imagine other shenanigans with xargs or something, but I think this strikes the best balance between performance and readability (as far as shell script goes).

read_int16 and read_int32 don't work on big-endian systems, or if int is 16 bits instead of 32. the latter issue can be easily fixed by explicitly specifying -td2/-td4, but the former issue is not so easy. I think it requires either figuring out the endianness beforehand, or better, something like this:

    od -An -tx1 -j"$offs" -N4 "$path" | while read a b c d; do
     echo $(((0x$a << 24) | (0x$b << 16) | (0x$c << 8) | 0x$d))
    done
oddly, this is used in ls-files already. and yes, I checked: 0x$a is POSIX, and the arithmetic evaluation size must be at least a signed long, which is at least 32 bits.

'for x in $y; do printf "$a%s$b" "$x"; done' is equivalent to 'printf "$a%s$b" $y' (assuming neither a nor b contain format specifiers). similarly, 'for i in {1..100}; do printf "$a"; done' is equivalent to 'printf "$a%s.0" {1..100}'. unfortunately, brace expansion is not POSIX, but these are both significantly more efficient (both in code size and execution time) than the loop methods.

sha1sum is not POSIX. I think shell arithmetic provides you enough tools to implement https://en.wikipedia.org/wiki/SHA-1#SHA-1_pseudocode directly, although it may be slightly slower than a C implementation. awk is probably faster than shell.






Such a long text... to end with arguing non-POSIX solution. But the initial goal of the project was having a POSIX code, and it can indeed be a valid goal. So the whole post is "a lot more complicated than it could be." Tl dr: you wouldn't make POSIX code.

what the fuck? I specified POSIX alternatives to non-POSIX uses in the code. only one feature, brace expansion, is not POSIX, so I specifically did not recommend its use.

Th specific part that I understood as your argument for non-POSIX solutions:

"'for x in $y; do printf "$a%s$b" "$x"; done' is equivalent to 'printf "$a%s$b" $y' (assuming neither a nor b contain format specifiers). similarly, 'for i in {1..100}; do printf "$a"; done' is equivalent to 'printf "$a%s.0" {1..100}'. unfortunately, brace expansion is not POSIX, but these are both significantly more efficient (both in code size and execution time) than the loop methods."

I didn't understand why you write that part at all, considering the goals of the program we discuss (which is to demonstrate some git primitives in POSIX compliant shell code).


'for x in $y; do printf "$a%s$b" "$x"; done' is used in the code already. I am proposing that it be changed to 'printf "$a%s$b" $y', which is also POSIX compliant, shorter (even including a comment), and faster. I included the part about brace expansion as a side note, not proposing that it be used.

> 'printf "$a%s$b" $y', which is also POSIX compliant, shorter

Yes, indeed, thanks for pointing that, it's documented:

"The format operand shall be reused as often as necessary to satisfy the argument operands."

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/p...


I’m sorry if I misunderstood you. I’m indeed interested in what from all you wrote is then what you would suggest to be changed, as I also looked at his code and also read here that it was done in short time so I also believer there are possibilities for improvement. Specifically, reimplementing sha calculation itself should be a non goal, in my opinion. Just that the .sh code itself works on all POSIX shells, not that the whole system has to be POSIX only: calculating sha in shell is surely not the point of demonstrating how git works.



Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: