in reply to Re: moving from mac to PC
in thread moving from mac to PC

... use slashes, not backslashes. WIN understand both ...

... except on the command line or with respect to anything handled by the command line interpreter (just for the sake of consistency):

c:\@Work\Perl>perl -wMstrict -le "my $path = '/@Work/Perl/monks/yngwi'; my @dirs = `dir $path`; print qq{@dirs}; " Invalid switch - "@Work". c:\@Work\Perl>perl -wMstrict -le "my $path = '\@Work\Perl\monks\yngwi'; my @dirs = `dir $path`; print qq{@dirs}; " Volume in drive C is Acer Volume Serial Number is 9480-355B Directory of c:\@Work\Perl\monks\yngwi 04/02/2011 05:51 PM <DIR> . 04/02/2011 05:51 PM <DIR> .. 04/02/2011 06:18 PM 2,255 detect_class_method_1.pl 1 File(s) 2,255 bytes 2 Dir(s) 64,490,688,512 bytes free
(This is under Win 7.)


Give a man a fish:  <%-{-{-{-<

Replies are listed 'Best First'.
Re^3: moving from mac to PC
by afoken (Chancellor) on Oct 28, 2016 at 06:27 UTC
    ... use slashes, not backslashes. WIN understand both ...

    ... except on the command line or with respect to anything handled by the command line interpreter

    The only real problem is the command interpreter. But if you use the command interpreter, your code is already far from being portable.

    How external programs handle command line arguments depends on the individual program. Most programs with a DOS legacy treat the forward slash as switch introducing character, as do many programs written for Windows. But programs from other platforms have no problems with forward slashes in file names on the command line.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
      I suspect that this is related to internal commands infact when you say individual program i suspect that internal commands do not like slashes, while all other ones accept both slashes and backslashes.

      See ss64.com where internal commands have a dot after the name.

      Given that dir and type are internal commands and ls (UnxUtils version) and icacls are not, you can see the difference:

      # dir not OK perl -wMstrict -le "my $path = 'c:/scripts/resized';my @dirs = `dir $p +ath`;print qq(@dirs)" Formato del parametro non corretto - "scripts". # ls OK perl -wMstrict -le "my $path = 'c:/scripts/resized';my @dirs = `ls $pa +th`;print qq(@dirs)" # OK long output omitted #type not OK perl -wMstrict -le "my $path = 'c:/scripts/resized/zen-small.pl';my @d +irs = `type $path`; print qq(@dirs)" c:/scripts/resized/zen-small.pl not found # icacls OK perl -wMstrict -le "my $path = 'c:/scripts/resized';my @dirs = `icacls + $path`;print @dirs" c:/scripts/resized BUILTIN\Administrators:(I)(F) BUILTIN\Administrators:(I)(OI)(CI)(IO)(F) NT AUTHORITY\SYSTEM:(I)(F) NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F) BUILTIN\Users:(I)(OI)(CI)(RX) NT AUTHORITY\Authenticated Users:(I)(M) NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M) Elaborazione completata per 1 file. Elaborazione non riuscita per 0 fi +le

      is fun also to see different languages for errors issued (italian coming from the OS and english).

      L*

      There are no rules, there are no thumbs..
      Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
        I suspect that this is related to internal commands infact when you say individual program i suspect that internal commands do not like slashes, while all other ones accept both slashes and backslashes.

        Actually, some MSWindows-centric programs also don't accept / in file paths. For example, last time I used Beyond Compare's CLI, it choked on / even when it was a path like "c:/path/to/file.ext".

        BTW, in MS-DOS, there was system call to change the "option switch" character. I don't remember what it was, but back when I had to use Win95, one of my mentors told me about it. Made the Win95 experience tolerable for me. Later, I discovered Cygwin.