Live data from Hacker News

A simple file encryption tool and format

docs.google.com

21–29 of 29 posts

Re: A simple file encryption tool and format

#21
post #20
post #19

Earlier quoted context omitted.

There are several standards that specify how offsets should appear, but only Go uses Z (meaning Zero offset, aka UTC equivalent) followed by what appears to be a _positive_ number to represent a _negative_ offset... By this logic we can expect to see a Moscow time stamp represented as HH:MM:SS+03:00 in every other program, and HH:MM:SSZ-03:00 only in Go. It's just wrong, for no good reason.

You are misunderstanding what you are seeing. The Z does not represent a literal Z in parsing/formatting. https://play.golang.org/p/Qp-bBtzKpG-

OK, Thanks for clearing that up.

Re: A simple file encryption tool and format

#22

Please please please use standard command line flag format (getopt_long) instead of the Go’s flag format. It’s super irritating that Go programs do it their own, less convenient way. For example: https://github.com/DavidGamba/go-getoptions

I’m not sure I understand, what’s the difference? I’ve never had any problems using go programs’ command line flags myself.

Re: A simple file encryption tool and format

#24
post #4
post #3

Could update link to age-tool.com.

I tried that link but got re-directed to the original Google Docs page. It sounds like a really interesting tool, but I haven't been able to find the actual code anywhere.

The repo: https://github.com/FiloSottile/age

Re: A simple file encryption tool and format

#26
post #16

Ugh, Go fails to parse RFC-3339 [0] correctly so our best hope for "Actually Good Encryption" will end up with badly formatted timestamps. Timezone offsets should be represented by either a "+" (positive offset) for hours added to UTC in zones East of the prime meridian, or a "-" (negative offset) for zones to the West. The Z suffix (meaning Zero hours offset from UTC, from the phonetic alphabet for "Zulu"), if it is…

> will end up with badly formatted timestamps.

I'm not sure why you think that. If rfc3339 format is required, then either a custom formatter can be created or a 3rd party lib can be used. Go may be silly in its stdlib, but it doesn't stop you from doing the right thing.

Re: A simple file encryption tool and format

#27
post #16

Ugh, Go fails to parse RFC-3339 [0] correctly so our best hope for "Actually Good Encryption" will end up with badly formatted timestamps. Timezone offsets should be represented by either a "+" (positive offset) for hours added to UTC in zones East of the prime meridian, or a "-" (negative offset) for zones to the West. The Z suffix (meaning Zero hours offset from UTC, from the phonetic alphabet for "Zulu"), if it is…

> will end up with badly formatted timestamps. I'm not sure why you think that. If rfc3339 format is required, then either a custom formatter can be created or a 3rd party lib can be used. Go may be silly in its stdlib, but it doesn't stop you from doing the right thing.

It turns out that although the examples aren't great, actually Go does do the right thing, so my mistake, as explained by lann some hours ago.

Re: A simple file encryption tool and format

#28

Please please please use standard command line flag format (getopt_long) instead of the Go’s flag format. It’s super irritating that Go programs do it their own, less convenient way. For example: https://github.com/DavidGamba/go-getoptions

I’m not sure I understand, what’s the difference? I’ve never had any problems using go programs’ command line flags myself.

I believe GP's remarks are that single hyphen followed by letters should each be individual flags, and double hyphen followed letters is a single flag in long form.

The application in question is using -generate rather than --generate.

Re: A simple file encryption tool and format

#29

Please please please use standard command line flag format (getopt_long) instead of the Go’s flag format. It’s super irritating that Go programs do it their own, less convenient way. For example: https://github.com/DavidGamba/go-getoptions

I’m not sure I understand, what’s the difference? I’ve never had any problems using go programs’ command line flags myself.

oarsinsync is correct.

The standard on most UNIX-like OSes is that long options, e.g. --long, have two dashes, and short options, e.g. -l, have one.

It allows you to combine multiple options into one. For example, the following two commands are equivalent:

    $ ls -laF
    $ ls -l -a -F
Post reply on HN