phutil_is_windows()

Side question, so I can submit a patch, is it a libphutil way to :

if (workflow_os == "Windows") {
  exec(window_feature);
} else {
  exec(unix_feature);
};

In T9441#146736, @franshamk wrote:

+1 for cygwin/babun support.

+1 for cygwin/babun support.

I'm fairly certain since it seems to be using the CreateProcess API as others do. I'm also using xonsh (the project using that Python code) for quite some time now and it works without any issues.

That seems tentatively fine, although it may only solve some of the problems here and may create new problems.

@epriestley - okay, may be the name mislead me. Anyways, I'm basically proposing making bypass_shell on by default in execx and implementing a mechanism that automatically finds the full path of the executable on Windows by implementing that Python function I referred to. Does this make sense?

I'm pretty sure that if execx() an editor like vim or nano, whether you use bypass_shell or not, it just executes it uselessly in the background and hangs forever. That is, the behavior of these two programs is very different on Linux, and I believe it will be very different on Windows no matter what bypass_shell is set to:

How does that obsolete PhutilExecPassthru?

How does that obsolete PhutilExecPassthru?

Okay, proposal: how about we implement the equivalent of this: https://github.com/scopatz/xonsh/blob/fa356d728b2852274f8aa0260dc7da3b7b0f08ab/xonsh/built_ins.py#L268

Oh god, and I thought Python's subprocess module was pretty bad.

D1938 is the actual origin, I think.

Oh, that diff just moved it, so it's actually older than that.

Possibly. We've used it in PhutilExecPassthru since D6774.

D14246 / D11396 / T6966 are about a specific Windows issue where the command name is treated differently from other arguments. That is, these commands mean different things:

bypass_shell (windows only): bypass cmd.exe shell when set to TRUE
5.2.1 Added the bypass_shell option to the other_options parameter.

Yes, it does.

Does vanilla cygwin include its own PHP?

Experiencing the same problem in 'vanilla' cygwin

I forgot about that. The Windows

mode

command will return the words such as "Columns" per the locale of Windows. So looking for literally "Columns" will only work for the English Windows locales.

As for the regex note that I am not the author of it,as stated in my comment above(maybe it has been overlooked because i didn't say that clearly),i have just taken it from stackoverflow(if that's ok) to provide a solution for this task as it seemed to be straightforward.As you said this regex looks really weird,I for myself would't even be able to form such an regex,but I am able to explain roughly in detail.
So mode contains in my case 2 blocks,one with sth others and the other with the headline containng CON,this regex looks for the first appearance of CON followed by an arbitary number of any characters following a : .As you have pointed it's better to use the con directly via mode con,i have added a patch that does it.The : is follwed by a sequence marked by ( ),this sequence is detected when a line break(\n occurs) followed by an arbitary number of characters without |,so every time a line break occurs it will trigger that sequence.THe 3 in the { specifies how many times this sequence should match in the text before the regex engine proceeds with the next statement(I bet you're aware of this),which is (?<cols>\d+).
I guess ?<cols> is to copy the matched contents of this sequence in to the key with cols in $matches,so it's redundant as basically every sequence marked with( is accessible by a number as key.The \d stands for digits,so as soon as the regex engine encounters a non-digit,it will abort.

"I see" said the blind man as he tripped over his code.

My suggestion was regarding the

`mode`

changing to

`mode con`

Which will limit the output of the mode command to only include the keyboard/console device, rather than running a blanket mode that returns status for all devices, then relying on the regex to locate the CON. I suggested this as a way that might reduce the complexity of the regex.

+1 vote from me to comment the use of regular expressions (how can anything that looks like this "'/CON.*:(\n[^|]+?){3}(?<cols>\d+)/" be called regular?)

I think the way forward here is likely:

Possibly a bug with PHP's implementation of escapeshellarg for Windows?

• https://bugs.php.net/bug.php?id=40928
• https://bugs.php.net/bug.php?id=43261

If you submit this as a differential revision it will give a better interface for others to review and discuss the suggested change.

I think my suggested code from stackoverflow for Windows behaves like its unix counterpart,as it outputs the same numberm,namely 80, and does not rely on the actual size of the terminal window.However,note,that I have not tested the following code in conjunction with phutil,only tested the code stated in my comment above.

I think this is a dup of T8298, T8291, etc.

More information:

Here is the code snippet for Unix/Linux:

In the code the unix Command tput cols is used. All this really does is look at the $TERM environment variable and infers the column count from that. On my Mint 17.2 this is 'xterm' and the tput cols command always returns 80 (which is the default column width for xterm).

preg_match('/CON.*:(\n[^|]+?){3}(?<cols>\d+)/', `mode`, $matches);
$cols = $matches['cols'];

This outputs the number of columns of the terminal window according to http://stackoverflow.com/questions/263890/how-do-i-find-the-width-height-of-a-terminal-window (it's a weird trick),so I assume the width can be concluded in some way from the number of columns. Tested it ,but however when resizing the window by mouse the number of columns stays the same,don't know whether this behaves exactly as the non-Windows implementation.

The recommended way of running Arcanist under Windows is from either the command prompt or msysgit, which can be installed from https://git-for-windows.github.io/, with the official PHP for Windows binaries installed in some directory and added to your PATH. Guidance on how to set up Arcanist on Windows can be found at https://secure.phabricator.com/book/phabricator/article/arcanist_windows/.

It's nicer not to add things to the path variable unless necessary. Also, manually uninstalling or changing the installation directory by changing your path is more arduous than altering a line in your PS profile. Arc runs perfectly well without adding anything except PHP to the path, therefore a function is a cleaner solution for powershell-specific installation instructions.

Will leave it open for now if anyone passing by has additional thoughts. If you can list the exact steps to reproduce, that would be helpful too (like which shells specifically have been tested).

I can't reproduce this.

You can also try arc set-config --trace editor .... to see the string arc is actually getting.

Windows shell behaviour is a big icky mess, and it doesn't help that there are so many variants of it. T6966, T8821 and T8298 are some of the tickets that describe this.

A work around is to add the notepad++ directory to the system PATH so you can then do:

Of course, I understand that the solution needs to be done properly in order to not break for others. I like the implementation in the diff you mentioned - it is not pretty but at least we contain the "hacks" in one place for the different environments. And who knows - maybe Windows 10 will give us a proper bash to use so that these problems will be long gone.

The problem is that escaping commands on Windows is thoroughly broken; there is no one solution that will work universally for everyone. Fixing this issue by changing the escaping so that it works under Command Prompt may well break it under msysGit, and it's important to understand in what situations the error occurs so that we don't cause regressions for anyone else.

In T8821#125999, @hach-que wrote:

Can you try running Arcanist commands under msysGit?

Can you try running Arcanist commands under msysGit?

In T8821#125997, @hach-que wrote:

We used the above script to install Arcanist this Friday (2 days ago). If you are running a version near that date or before it, then it's definitely an environment issue as the script works fine.

The only real issue with this approach is that there is a limit to the PATH environment string so what I had to do was to shorten all my entries by converting everything to DOS paths.

This is somewhat concerning; I have no idea what effect this will have.

I do not run msysGit Bash

You'll need Git installed for even the most basic of Arcanist commands to work (how did you clone Arcanist / libphutil without having Git installed?)

We used the above script to install Arcanist this Friday (2 days ago). If you are running a version near that date or before it, then it's definitely an environment issue as the script works fine.

In T8821#125993, @hach-que wrote:

I don't understand where these issues are coming from; we have several developers that use the latest version of Arcanist and libphutil on Windows without issue.

I think what needs to be established:

• How did you install PHP?
• What version of PHP are you using?
• Does Arcanist work fine under msysGit Bash?
• Does Arcanist work fine under Windows Command Prompt?
• Does Arcanist work fine under Windows PowerShell?
• What value do you have for system-wide PATH?
• Is both arc.bat and php.exe in your system-wide PATH?

For reference, this is the Powershell script we use to install Arcanist on developer machines (replace the URL https://code.redpointsoftware.com.au/ with your own instance). On a fresh install of Windows (or an install of Windows that does not have PHP or Arcanist installed), run this under an Administrator Powershell prompt and restart the computer.

I don't understand where these issues are coming from; we have several developers that use the latest version of Arcanist and libphutil on Windows without issue.

Seeing this issue on the following machine:

It was a case of operator error in this situation in following workaround T2465: Context not available for revisions created on Windows by @raman.rathod. (The path has to be in double-quotes, and spaces were omitted in "Program Files (x86). Simple case of everybody knows, so nobody knows.

I ran into the same issue with the default install of git-bash on Windows (8.1 x64), I ended up adding a function to my bash profile as per @michas2 idea:

This has been driving me and one of my colleagues crazy for a while now and he came with the following Stylish rule to get rid of it:

Summary of a conversation I had about this with @epriestley on IRC: