In this case, no, because if I have "control" over the strings, I use a / anyway all the time. Here is an example where it is not sufficient:

I have a directory path with / as separator, and I want to append to this directory a relative path of subdirs. This path I get from %ENV. The user is allowed to use either Windows or Unix style separators. If I want to form a consistent path (say: Unix style), then I need to translate the backslashes in the user-supplied path to forward slashes.

This is only a simple example. Other examples are: Translating a Unix path to Windows (for usage in a generated BAT file) or vice versa (for usage in a generated piece of bash script).

Let me emphasize that all these transformations are easy to do. I just thought that *if* someone has published a module with such features, it would not only be helpful, but would maybe also contain other useful stuff for mixed-OS environment development.

If I want to form a consistent path (say: Unix style), then I need to translate the backslashes in the user-supplied path to forward slashes.

(My original reply has already been downvoted ... which is not a good sign ... though that depends upon who downvoted it, and why.) On windows, I generally find that it doesn't matter whether the user supplies / or \ as the path separator. For example, this works fine for me on windows (where the /_32/pscrpt/inline folder exists):

use strict;
use warnings;
use Cwd;

my $path = '/_32/';
my $user_supplied = 'pscrpt\inline';

my $ok = chdir($path . $rel);

print $ok, "\n", getcwd(), "\n";
__END__
prints:
1
C:/_32/pscrpt/inline
[download]

In this case there's clearly no need for you to translate the backslashes to forward slashes. (I imagine that on Unix, however, things might be a little different :-)

Other examples are: Translating a Unix path to Windows (for usage in a generated BAT file)

Windows bat files will recognise the forward slash as a path separator ... at least that was the case for my test. (My test was to add "C:/b" to the path via a bat file, then check that an executable in C:/b ran, even though C:/b was not my cwd.)

Cheers,
Rob