Closed MarkDBlackwell closed 7 years ago
I'd say that it should appear how Windows users expect it. Instead of Your new Hugo site is created in "C:\\Mark\\develop\\try-hugo\\cygwin".
as the current output is, it should be Your new Hugo site is created in "C:\\Mark\develop\try-hugo\cygwin".
.
Personally, I'd prefer the forward slash but that's because I am a Linux user. Windows uses backslashes and so that's what should be used. All those double slashes is the bug here.
@felicianotech I suppose you're right, for the case where people are running on cmd.exe directly. :)
In that case (when running cmd.exe
), perhaps the output should be:
>hugo new site cmd
Your new Hugo site is created in "C:\Mark\develop\try-hugo\cmd".
2. ...You can add single files with "hugo new <SECTIONNAME>\<FILENAME>.<FORMAT>"
>cd cmd
>hugo --verbose
INFO: 2016/08/30 17:20:09 hugo.go:466: Using config file: C:\Mark\develop\try-hugo\cmd\config.toml
INFO: 2016/08/30 17:20:09 hugo.go:574: C:\Mark\develop\try-hugo\cmd\static\ is the only static directory available to sync from
INFO: 2016/08/30 17:20:09 hugo.go:612: syncing static files to C:\Mark\develop\try-hugo\cmd\public\
WARN: 2016/08/30 17:20:09 site.go:2028: Unable to locate layout for homepage: [index.html _default\list.html]
WARN: 2016/08/30 17:20:09 site.go:2004: "\" is rendered empty
I am a Linux user.
Then, perhaps you haven't struggled with Windows' difficulties!
When running Git For Windows or Cygwin, we don't expect, and cannot type, (\
) as a directory separator. Under them, (\
) is an escape character, just as it is in Unix.
Both Git for Windows and Cygwin only display and accept forward slash (/
) as a directory path separator.
However, I suppose many people on Windows use Hugo without Git for Windows or Cygwin.
I wonder if there's a way for Hugo to detect it's running in such a Unix-like environment on Windows?
BTW, Cygwin supplies no binary package for the Golang compiler. The usual Windows one works, just fine. As I understand, the environment for which Golang itself was compiled normally determines its sense of which OS it's on.
Here's a quick survey of the ways other languages and software handle the Windows backslash directory separator. In short, all these recommend, for entry, that users instead use the forward slash (/
) as the directory separator:
Chef:
On Windows, Chef [on output] will convert absolute paths with forward slashes (/
) to use the Windows-style backslash character (\
). In this book, we’ll stick with using forward slashes (/
) on Windows.
"We're thinking of changing it to be (/
) for everything, specifically to resolve some VFS concerns. Resolution set to fixed."
"Note that on Windows, both the backslash (\
) and the slash (/
) are in principle valid directory separators. This module treats them both on equal footing."
"[On Windows] you should always use (/
) as your path separator. (\
) is the escape character in nearly every programming language in the world, and it was a really poor choice for the DOS guys to use it for exactly reasons like this. YOU should always use (/
)."
"Doubling up backslashes is most notable when entering full path names in Maple. For this situation it is easier to use forward slash instead. Forward slash is recognized as a directory separator on all platforms including Windows."
"In Python, there are a number of functions in the os.path module that change forward slashes in a string to the appropriate filename separator for the platform that you are on. One of these functions is os.path.normpath(). The trick is to enter all of your filename strings using forward slashes, and then let os.path.normpath() change them to backslashes for you."
"Windows users should note that specifying a working directory in R requires forward slashes and not backslashes."
"The following example shows how to set the working directory in R to the folder 'Data' within the folder 'Documents and Settings' on the C drive.
# Set the working directory
setwd("C:/Documents and Settings/Data")
Remember that you must use the forward slash (/
) or double backslash (\\
) in R! The Windows format of single backslash (\
) will not work."
@MarkDBlackwell it seems like there are two parts to this that need to be fixed:
Do you feel those would both solve this issue?
I assume Hugo will continue to prefer the backslash character as the filesystem path separator in its messages on Windows.
Using cmd.exe
(or Git for Windows or Cygwin), this warning continues to emit the other strangely-doubled backslash from my initial report:
>hugo new site cmd
>cd cmd
>hugo --verbose
WARN: {timestamp} site.go:2373: "\\" is rendered empty
@MarkDBlackwell we can use the filepath.Join(<path>)
to generate the filesystem path so that it's dependent on your OS and not a preference of Hugo itself (this is how it should be 😀). My PR should resolve the original issue you had.
In the original issue it was being printed as %q
which adds the escape characters in strings, so I've updated it to use %s
.
@chaseadamsio thank you for that information.
Yes—you are completely right that your commit's changes (here and here) have resolved for Windows the messages output by the hugo new site
command.
The other, problematic message (which I mentioned earlier today and originally) is output by the hugo --verbose
command, and contains a path associated with the as-yet-ungenerated home page file. This message is untouched by your commit 3616fb6:
WARN: {timestamp} site.go:2373: "\\" is rendered empty
I suppose this \\
should be /
if it's a URL path, or \
if it's a filesystem path.
yep, that's an easy fix too. @spf13 or @natefinch is there a reason on formatting output from hugo defined values is rendered with %q
vs %s
? If not, I can also submit a PR for this particular issue, but it seems there are a lot of places where it's rendering safely with the escape /
that should probably be cleaned up.
\\
here is the path to your root I believe.
I don't believe there was a good reason On Mon, Oct 10, 2016 at 7:11 PM Chase Adams notifications@github.com wrote:
yep, that's an easy fix too. @spf13 https://github.com/spf13 or @natefinch https://github.com/natefinch is there a reason on formatting output from hugo defined values is rendered with %q vs %s? If not, I can also submit a PR for this particular issue, but it seems there are a lot of places where it's rendering safely with the escape / that should probably be cleaned up.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spf13/hugo/issues/2401#issuecomment-252770286, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKlZIJyoJIb94Z3pgWSAavEM4B0_Fk9ks5qysYmgaJpZM4JxFtJ .
@bep I've updated the last request from @MarkDBlackwell in #2565, can you let me know if it's needs to be modified?
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Currently, in some Hugo messages, the directory separator appears as a doubled, backslash character (
\\
). This happens while using any of:cmd.exe
.Presumably, most Hugo users on Windows use Git. Of that group, most use Git For Windows. Some use Cygwin.
But that may not matter, because Hugo's messages look the same, even when directly using
cmd.exe
.Most Hugo users on Windows IMO would prefer the directory separator in Hugo's messages to appear as a single, forward slash character (
/
) — always, in all three scenarios.Most Windows users are acclimated to seeing forward slashes used as a directory separator in messages. That doesn't bother us.
To sum up, I've seen
\\
appear in at least the messages:Your new Hugo site is created in (path)
; and(path) is rendered empty
.\
appears in most messages, but not all.Some messages contain the desirable IMO
/
.Following is some output (with some lines elided) which reveals this
\\
problem happening in all three scenarios: Git For Windows, Cygwin, andcmd.exe
. Again, Hugo's behavior is identical in all three.Running Git For Windows, we see:
Running Cygwin, we see the same:
When running on
cmd.exe
directly (without Git For Windows), we see the same: