EG should understand windows paths

[tomrvincent]

I have a drive accessible to both Linux and Windows. 

So, I should be able to use 'S:/_Pennsylvania/Claims Processing/'

But no...I have to use '/mnt/nfs/prod/Teams/statutory/REGREP/_Pennsylvania/Claims Processing/' instead.

Also, if EG can import from my F drive (a Windows only drive), I should be able to use F in a proc import statement.  Same with export.

[ballardw]

The first issue is UNIX and derivative OS limitations and blame Bill Gates ( and likely lawyers) for implementing paths with \ instead of /.

You might be able to implement a solution by defining a macro variable that holds the

/mnt/nfs/prod/Teams/statutory/REGREP and use that macro reference for your "S" drive?

[ChrisHemedinger]

@tomrvincent - Your EG client is running on Windows, which can see your Windows resources including mapped drives.  But your SAS session -- where your code runs -- is on Linux.  You need to define your data locations/files in terms relative to that endpoint.  

You're actually fortunate that both EG and Linux can see the same network locations -- lots of customers don't have that, and managing files is trickier.  But the burden is on you (unfortunately) to understand which actions EG performs versus the actions that SAS performs.

[Kurt_Bremser]

The idiotic use of backslashes and drive letters is a legacy stemming from the CP/M roots of DOS. In CP/M, the slash was used for commandline parameters. Since DOS was (along with its platform, the 8086) designed to take over from the Z/80 (that's why it had 64k segments, which is the complete address space of a Z/80), it was nothing more than a CP/M port to the 16-bit processor which Gates and Allen bought from its programmer since they needed it right now and had no clue how to build a system.

When they grafted a hierarchical filesystem (then mainly known from UNIX) onto that concoction, they had to use another delimiter, or all the CP/M software would have to be rewritten to use the dash for commandline parameters common in UNIX. Same goes for drive letters, which are unknown when you have a single filesystem hierarchy.

Since SAS and EG can have no idea on their own how your Windows shares are mounted on UNIX (or UNIX shares are mounted on Windows desktops), you as the user would have to maintain a mapping resource for EG. Maintaining that would be no less challenging than knowing the correct UNIX paths in the first place.

[tomrvincent]

@ChrisHemedinger I know that, Chris, but EG clearly knows the Windows drives since it can import/export to them.  EG should be able to translate them in code as well.  The current state is clumsy.  You folks ask for suggested improvements and respond with 'the burden is on you'?  All I'm asking for is to extend whatever process allows EGs to import/export from Windows paths to programs as well:  When it hits a MSDOS path, convert it to a Linux path or transfer the file.

[tomrvincent]

@Kurt_Bremser clearly EG knows how to navigate Windows paths or you wouldn't be able to import/export files from/to Windows paths.

[ChrisHemedinger]

@tomrvincent In the Import/Export case, EG isn't writing the code for SAS to read/write from your local desktop.  Instead, EG lifts the file and uploads it to SAS, then generates import code to work from there.  I've got a blog post that describes this.

"File location" is one of the big challenges that SAS users encounter when moving from local SAS to a remote SAS via EG or SAS Studio -- and any ideas to make this easier are certainly welcome.  I wanted you to understand that the perception that EG generates local-drive-centric code sometimes but other times forces you to think in Linux terms...that's not exactly true.  EG is moving files behind the scenes to make the wizards do their work.

[tomrvincent]

@ChrisHemedinger I understand what it's doing.  I'm asking to extend that  'moving files behind the scenes' (actually copying) to normal coding.  There shouldn't be any difference between the import task and proc import.  More importantly, it would allow me to target Windows folders that Linux doesn't know about (but that EG does).

[ChrisHemedinger]

@tomrvincent Gotcha, I understand the request now.  When you write code that references a local file, but run on a remote server, then upload that file so SAS can see it.  Likewise, if you write code that exports a file to a local path, download that file.

The suggestion now makes sense to me, but I can't see it as feasible.  There are too many nuances to file paths that appear in code to reliably guess when a file target is local or remote.  Macro variables, filerefs, and other mechanisms confound this.  Also sometimes the remote server is Windows based too, so a Windows path in the SAS session (C: drive for example) is not the same as what EG sees (your local C: drive).

That's why the Copy Files task exists in EG.  You can control exactly which files to move and where they should go, and then write your code accordingly.  I have an example of how to use this here.

[Tom]

Could SAS make an EG filename engine to allow the SAS server to talk to the Enterprise Guide user's machine? 

Perhaps similar to the PC-Files server? Or other engines like FTP, URL etc?

Then your SAS code could reference the Windows path and it would be pushed to EG to handle.

filename PCP EG 'S:\_Pennsylvania\Claims Processing\' ;
data want ;
  infile PCP('new_file.txt') dsd truncover firstobs=2 ;
  input var1-var3;
run;

[ChrisHemedinger]

You could install/enable an FTP server on your local Windows box.  Then you could use the FTP FILENAME. (And give your admin a heart attack.  😉 )