The system cannot find the path specified.

[jbasinger]

I'm using Windows 10 with version 2.2.4 of Ruby and am getting an error saying, "The system cannot find the path specified." I haven't messed with Ruby for a while, so I might be doing something foolish. Here is my example code.

gem 'pastel'
require 'pastel'

pastel = Pastel.new
puts "Using Pastel Version #{Pastel::VERSION}"
puts pastel.red('This should be red!')
puts "\e[32mfoo\e[0m \e[31mbar\e[0m"

And here is the output:

The system cannot find the path specified.
Using Pastel Version 0.6.1
This should be red!
foo bar

The "This should be red!" output, is not colored at all. But, the next line "foo bar" is colored green and red as expected using the \e codes.

I tried poking around the source a bit but couldn't find a spot where the library would be looking for some external file. Any idea what could be going on?

[piotrmurach]

Hi Justin, thanks for using the library.

I think I know what the problem is, the Pastel relies on the tty-color to determine console support for ansi color escape codes. Hence I think the path error is actually being generate by that dependency. As far as I know, Windows 10 is the first one to introduce 'native' simulation of terminal ansi chars. I don't use Windows myself but I would love to improve the situation. To test my theory you should be able to force coloring by passing :enabled option which skips automatic detection.

pastel = Pastel.new(enabled: true)
puts pastel.red('This should be red!')

I'd really like your input on this one as a Window's user. I think there are two paths we could investigate. One is to drop the tty-color dependency and basically let clients determine the logic for enabling the option of strings coloring. Second one would be to work on tty-color itself to improve it's detection of color support on windows(i'm thinking of using win32api to directly query system). Any thoughts? Would you have time to contribute to tty-color and help fix the situation on Windows?

[jbasinger]

Using then enabled flag made everything work. I dug a bit deeper into the code and found that it's actually the tty-color support code that is sending that error.

https://github.com/piotrmurach/tty-color/blob/master/lib/tty/color/support.rb#L47

tput doesn't exist in Windows, so it returns false and also outputs the error from the terminal when it can't find that system command. Even if the from_tput function were to fail a little better, things would crash in the from_curses function as Windows doesn't support that either.

I'd love to submit a pull request to you with the fixes. I'm thinking some checks in those functions to just return false if the OS is Windows and a from_windows function in the support module. I don't have a lot to go off in the terminal to tell if colors are supported other than what OS it is. I checked both the classic and new Windows 10 terminal with the enabled: true flag and it seemed to work fine. How would you feel about adding tty-platform as a dependency to the tty-color component?

[piotrmurach]

I think we would need to be careful in our assumptions. On Windows user can be running Cygwin, Tera Term(True Colour emulator), ConEmu and hence have access to standard shell utilities in which case tput will run just fine. I think it would be safer to check if tput utility exists using for example tty-which. I probably wouldn't worry about from_curses call as it will silently fail with LoadError and simply return.

I think special from_... for windows would make sense. I'm happy to add tty-platform dependency but I still think that checking OS may not be the right approach. Checking for features is probably better to go about it. Having said all that I think it would be safe to assume that certain version of Windows above a given version should all support 16 colors?

[piotrmurach]

I think Windows 10 internal console only understand a limited set of color attributes see, so you may not be able to even use all the 16 currently supported.

[jbasinger]

I totally agree with the feature testing idea, I didn't even consider Cygwin or the like. I ran your palette example in both the current Win 10 console and the legacy console. They both seem to react the same way. Although, I feel like there was a way to get the bolded versions of the colors in Windows. I'll see if I can dig into that a little bit more as well. Would bold red be the same as bright red? I've attached a couple screenshots so you can see.

Legacy console

Normal console

[piotrmurach]

It's been a long time, but I have finally sorted the error out in tty-color. I have also by default enabled pastel to color strings in windows console. I think this is a good default since detecting color support on Windows is rather hard task and you have demonstrated that basic colors work pretty well even in old Windows console. I have released v0.7.0. Enjoy!