Straight.el: Add support for Microsoft Windows

[theldoria]

Currently straight.el depends on symlinks and find under the hood. It, therefore, can not be used on Microsoft Windows, unless a Cygwin based Emacs installation is used.

This issue is a request to implement specific support for the Microsoft Windows platform Version 7 or higher.

Proposal:

• symlink: Microsoft Windows comes with similar features, called junctions, and symlinkd, both to be created with mklink.. The difference between both is explained here. Which one is better must be decided and tested.
• find: On could either try to adapt to Windows built-in find command, depend on a Unix find for Windows (e.g. MiinGW msys) or probably replace dependency on find altogether. Maybe someone knows of a system independent _find-file_ emacs package that could be used as a replacement?

[raxod502]

Just so everyone knows, this feature will have to be implemented by somebody else who provides a pull request, since I do not use Windows and cannot test any changes for it. I'm all for supporting more platforms, though.

[raxod502]

Blocks #146.

[raxod502]

I have been informed by @PythonNut that straight.el works on WSL. If you are interested in trying straight.el on Windows, this would be the easiest way.

[theldoria]

Would be nice, however, I am forced to use Windows 7.

[Ovsyanka]

There is another workaround about that problems. First is https://github.com/raxod502/straight.el/issues/124#issuecomment-331739964.

Symbolic links

There is two options:

• Links working nice when you running emacs as administrator.
• You can try to add rights to make links to your user, as described here. But if your user in Administrators group it will not work.

Find

upd: There some problems accured one by one.

1. The find utility i suggested haven't -newermt option used in straight.el. The 4.4.2 from minGW has it.
2. Then this error appears:

error: Command failed: find "." "-name" ".git" "-prune" "-o" "-path" "./straight.el/*" "-newermt" "2017-10-13T23:12:51+0200" "-print":
/usr/bin/find: paths must precede expression: ./straight.el/Makefile

It can be fixed by replacing (format "./%s/*" local-repo) to (format "'./%s/*'" local-repo) in straight.el

1. Then this error appears:

error: Command failed: find "." "-name" ".git" "-prune" "-o" "-path" "'./straight.el/*'" "-newermt" "2017-10-13T23:12:51+0200" "-print":
/usr/bin/find: I cannot figure out how to interpret `2017-10-13T23:12:51+0200' as a date or time

It can be fixed by changing (mtime (format-time-string "%FT%T%z"))) to (mtime (format-time-string "%F %T%z")))

I got it here.

1. Download precompiled find utils from ezwinports (findutils-4.2.30-5-w64-bin.zip for example) and unpack the archive into emacs folder.
2. Add the bin path of findutils (in my case that is emacs bin folder) at the beginning of the exec-path.
(setq exec-path (add-to-list 'exec-path "c:/programs/emacs-25.3_1/bin"))

[raxod502]

Links working nice when you running emacs as administrator

But you would _always_ need to run Emacs as an administrator, since package rebuilding could happen at any startup. That doesn't seem like a very good idea to me.

On the other hand (keeping in mind I have never used Windows), it looks like you could grant permissions to yourself for symlink creation.

[Ovsyanka]

But you would always need to run Emacs as an administrator, since package rebuilding could happen at any startup. That doesn't seem like a very good idea to me.

For me too. I called it as "workaround" because it not solves issue, but you at least can use straight.el on Win before this issue will be actually solved. As I understand, you need to run as Administrator not always, but when you modifying your package setup.

Your approach about "grant permissions" seems great! But in my case it didn't work because my user in Administrators group. In other case it should work. This bug (or feature?) explained here.

[Ovsyanka]

@raxod502, I have a question about code

;; This time format is compatible with BSD and GNU find(1).
          ;; Which is why we're using it, of course.
          (mtime (format-time-string "%FT%T%z")))

I have few linux setups with CentOS 6/7 and this format not accepted there:

> find . -name .git -newermt 2017-10-13T23:12:51+0200 -print
find: I cannot figure out how to interpret `2017-10-13T23:12:51+0200' as a date or time

> find --version
find (GNU findutils) 4.4.2

I think if I will setup straight.el on those linuxes I will have this error.
Same picture on my Win machine. Could you test in your environment the same format without T between date and time "%F %T%z" instead of "%FT%T%z"?

[raxod502]

It seems like it works, so I applied the change in https://github.com/raxod502/straight.el/commit/e7b096d13e261a17c66f69932009b71e2295dc57.

[Ovsyanka]

Cool. I suggest you to consider applying the second change I made: replacing (format "./%s/*" local-repo) to (format "'./%s/*'" local-repo). I just added '. And I think it is actual for linux too - look at explanation.

[raxod502]

The find(1) command is run using call-process, whose arguments are not subject to shell interpretation. Did adding quotes fix a problem for you?

[Ovsyanka]

Did adding quotes fix a problem for you?

yep

[raxod502]

… can you elaborate?

[Ovsyanka]

Hm. I am not understand what do you mean "elaborate" =/
Could you ask a particular question?

[raxod502]

Sorry. I meant, what was the problem you encountered, and why did adding quotes solve it?

[Ovsyanka]

Ah, look at my https://github.com/raxod502/straight.el/issues/124#issuecomment-336653928

There is error on my machine:

error: Command failed: find "." "-name" ".git" "-prune" "-o" "-path" "./straight.el/*" "-newermt" "2017-10-13T23:12:51+0200" "-print":
/usr/bin/find: paths must precede expression: ./straight.el/Makefile

And I gave you my assumption about reasons in https://github.com/raxod502/straight.el/issues/124#issuecomment-336681061 (supposed reason). Seems like you don't think that it is the reason, but anyway, quotes solves this error.

[raxod502]

Oh, I'm sorry. I saw points 1 and 3 in that comment, but somehow missed 2. I guess that somehow shell expansion happens on call-process arguments for Windows? I'd like to figure out why that's the case, since adding single quotes to the argument is not really correct on other systems.

[Ovsyanka]

Hm.. Actually I am not familiar with emacs (it is my first install) so I am not sure that I could investigate this. I will try. More or less I got your point. But could you explain why it is "not really correct"?
_BTW, did you thought about some chat related to straight.el? Like Discord or gitter or IRC or anything else?_

[raxod502]

Let me demonstrate. We have a small shell script:

foo % pwd
/private/tmp/foo
foo % ls -lA
total 8
-rwxr-xr-x  1 raxod502  wheel  21 Oct 15 11:46 count-args.sh

As shown, it counts its arguments:

foo % cat count-args.sh
#!/bin/sh

echo "$#"

We can test this in the shell:

foo % ./count-args.sh foo bar baz
3
foo % ./count-args.sh foo "bar baz"
2

As you can see, in the first case all three words are passed as separate arguments. However, in the second case, bar baz is passed as a single argument, because it is quoted.

Now observe what happens in Emacs:

(call-process "/private/tmp/foo/count-args.sh" nil t t "foo" "bar" "baz")
;; => 3
(call-process "/private/tmp/foo/count-args.sh" nil t t "foo" "bar baz")
;; => 2

As you can see, each argument to call-process is passed directly to the program being invoked, and additional quoting is not necessary. In fact, check out the following:

(call-process "/bin/echo" nil t t "'./straight.el/*'")
;; => './straight.el/*'

As you can see the single quotes were not interpreted by any shell, and were instead passed directly to find(1). Wildcards will not be interpreted by a shell either. In your case, it looks like somehow call-process behaves differently and the wildcards _are_ interpreted by a shell (Windows being silly again, presumably).

On most systems, it's wrong to add additional quoting in this manner, since it's not needed and in fact will mess things up, since find(1) will be looking for files with single quotes in their names. I don't know what's going on with Windows.

[Ovsyanka]

Yeah, I see. I made some tests and seems like it is as you say:

... somehow call-process behaves differently and the wildcards are interpreted by a shell ...

And I can add, that seems like firstly wildcards interpreting and then all arguments passed directly to find. Because if I use spaces in names like test path* - then args like test path_1 and test path_2 will be sended and handled properly.

I dont think I can help you with that =/ I see why adding quotes in code is bad and haven't any other suggestions.

[raxod502]

And then magic happened.

(Please open a new issue if you find a bug.)

[raxod502]

cc @syl20bnr: Now we have Windows support.

[holocronweaver]

Update README to mention Windows support?

[raxod502]

@holocronweaver This is done as part of the referenced commit. It's on develop only at the moment.

[syl20bnr]

Good work!

I won't have time to work on it until 0.300 of spacemacs is released, I plan to look at straight.el during christmas holidays. This is good news that it is now compatible with windows.

[raxod502]

@syl20bnr Sounds good. And coincidentally, christmas holidays is when I will have free time to work on straight.el, too. Please feel free to ask all the questions you may have about the implementation and use cases!

[MikeTheGreat]

Mind if I ask if the main branch and/or the version in ELPA supports Windows?

[holocronweaver]

@MikeTheGreat Works for me on Windows using the main branch.

[MikeTheGreat]

Whoops - I didn't see that this was marked 'closed'. Serves me right for jumping right here from a search engine, and trying to read it on my phone :/