On Tue, 18 Oct 2016 06:47:23 -0600 Mike Hodson <[email protected]> wrote:
> On Tue, Oct 18, 2016 at 5:33 AM, Edward K. Ream <[email protected]> > wrote: > > Daily builds > > > > There is no hash data whatsoever available when downloading using > > the > latest > > link on Leo's download page. Other download links do provide > > "funky" hash data in the .zip file's filename, but apparently users > > never notice this data. The discussion of daily downloads has been > > a red herring. > > I thought I made it clear there _was_ the zipfile comment? Or are you > implying that a subset of the total counts as "whatsoever"? > Opening this in Ark is a much nicer experience than with > Infozip(cli) : You're correct that GitHub includes the hash in .zip files as a comment, but the goal is to be able to say to the user "paste the info. from the top of the log" (the log being the Leo log pane, not the unzipping output. There's no easy way for Leo to find the .zip file it's run from, so it can't report that for the user. If we dump the current timestamp ID, the most unambiguous ID will be that .zip file comment, or the hash in the foldername if the user doesn't use master.zip or rename the folder, but it's a lot of fiddling around to ask users to dig up that information. Cheers -Terry > (clicked "latest" within your last message, let Chrome launch the > system mime-specified app for it instead of just hopping into the > terminal and going at it with bash) > So it _does_ have a hash; somewhat hard to find, but it _is_ there. > > The "Snapshots" installation instructions are completely wrong when > they state: > > "As of 2014 .zip snapshots can be downloaded directly from github, no > account required. The downloaded file will have a name like: > leo-editor-50c070b715b9fec50c31be5853055a0ebc72cad5.zip" > > I'll show you how many ways this does not work below. Further, I do > see that the "X ago" links do contain directories where the exact > hash is expanded into the directory name. This is immediately > visible, for anyone who understands what a GIT hash is. > For me, who _is_ aware of git, and uses it normally, but decided to > test out your mentions of how things should work with the zips, and > found them to be factually inaccurate, this would be fine, if the > "master" Github file also used this. For being a user of git, but > not knowing the nuances of Github, I did not realize I needed to look > in the comments. Using a CLI Zip program that spat out the comment at > the _beginning_ of 2000 files verbosely written to my terminal, (no > thanks to infozip for that moderately annoying default) versus a GUI > archiver further isolated me from the existence of this. > > Just tell us to look _there_ because its existence is known, proven, > and works 100% of the time someone downloads -any- zip from Github. > > > So, here are 3 ways that "the filename will always contain the hash" > fails, as utilized by (perhaps(hopefully more than just a few)) > people who grew up with DOS and still love as many console windows > open as they can multiplex onto a window before the tab names become > indistinguishable. > > > 1: wget trusts the URL you feed it, as it filename of the output > file, even if the server redirects in the process; this is a default > that can be reversed, its effects below. > > mike@odin ~/leo-test $ wget ' > https://github.com/leo-editor/leo-editor/archive/master@%7B1%20day%20ago%7D.zip' > > --2016-10-18 06:30:24-- > https://github.com/leo-editor/leo-editor/archive/master@%7B1%20day%20ago%7D.zip > Resolving github.com... 192.30.253.112 > Connecting to github.com|192.30.253.112|:443... connected. > HTTP request sent, awaiting response... 302 Found > Location: > https://codeload.github.com/leo-editor/leo-editor/zip/6b14284f128f2997f3e31e545f27684d1d523ccf > [following] > --2016-10-18 06:30:24-- > https://codeload.github.com/leo-editor/leo-editor/zip/6b14284f128f2997f3e31e545f27684d1d523ccf > Resolving codeload.github.com... 192.30.253.121 > Connecting to codeload.github.com|192.30.253.121|:443... connected. > HTTP request sent, awaiting response... 200 OK > Length: 9502912 (9.1M) [application/zip] > Saving to: ‘master@{1 day ago}.zip’ > > master@{1 day ago}.zip > > 100%[================================================================================>] > > 9.06M 9.82MB/s in 0.9s > > 2016-10-18 06:30:25 (9.82 MB/s) - ‘master@{1 day ago}.zip’ saved > [9502912/9502912] > > mike@odin ~/leo-test $ ls -l > total 9300 > -rw-r--r-- 1 mike users 9502912 Oct 18 06:30 'master@{1 day ago}.zip' > > 2: And if you think you can get away from this by telling wget to > trust remote filenames? > $wget --trust-server-names ' > https://github.com/leo-editor/leo-editor/archive/master@%7B1%20day%20ago%7D.zip > ' > > Nope. > > mike@odin ~/leo-test $ ls -l > total 18568 > -rw-r--r-- 1 mike users 9502912 Oct 18 06:32 > 6b14284f128f2997f3e31e545f27684d1d523ccf > -rw-r--r-- 1 mike users 9502912 Oct 18 06:30 'master@{1 day ago}.zip' > > 3: Curl? Oh boy it doesn't even follow the redirections. > > mike@odin ~/leo-test $ ls -l > total 18572 > -rw-r--r-- 1 mike users 9502912 Oct 18 06:32 > 6b14284f128f2997f3e31e545f27684d1d523ccf > -rw-r--r-- 1 mike users 160 Oct 18 06:35 > master@%7B1%20day%20ago%7D.zip -rw-r--r-- 1 mike users 9502912 Oct 18 > 06:30 'master@{1 day ago}.zip' > > This is a 160 byte redirect HTML output: > mike@odin ~/leo-test $ cat 'master@%7B1%20day%20ago%7D.zip' > <html><body>You are being <a href=" > https://codeload.github.com/leo-editor/leo-editor/zip/6b14284f128f2997f3e31e545f27684d1d523ccf > ">redirected</a>.</body></html> > > So I propose simply let people know that even if the file is > mal-named, it _still_ has the hash _in the comment!_ > > > > > > Elegant? no. > Exists? and without much effort on the user end and 0 on yours? yes. > > Simply one _should_ be informed to look for it. Coding around a simple > bug-reporting requirement of "please note the version manually, it > exists 'here'" is time wasted. > > "Use GIT itself" > "Look in ANY snapshot's ZIP FILE COMMENT" > > Red herring? no. Legitimate problem with a simple manual solution? > yes. > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
