Can pipe option and encoding= option take effects at the same time?

[whymath]

My operation system is encoding as EUC-CN and I work on SAS DMS in Unicode enviroment. I'm trying to write a program to get the directory of some path on my compute. My first version of code like this:

%let path = %sysfunc(pathname(sasuser));
x dir "&path." /b/s > "&path.\_dir_.txt" & exit;

data test;
  infile "&path.\_dir_.txt" truncover encoding = 'zeuc';
  input path$1024.;
run;

x del "&path.\_dir_.txt" & exit;

It works. But I think there is a more effective and beatiful way, so I rewrite it. My second version of code like this:

data test;
  infile "dir ""&path."" /b/s" pipe truncover encoding = 'zeuc';
  input path$1024.;
run;

It's much shoter now, but is grammarly wrong:

ERROR 23-2: option name "encoding" is invalid.

How do you think of that? Can pipe option and infile= option take effects at the same time?

[ChrisNZ]

It seems that device pipe and option encoding= cannot be used at the same time, though that is not specified in the documentation.

You might want to ask tech support to have this clarified.

There is also a Feedback link all pages, including the relevant one:  https://documentation.sas.com/doc/en/vdmmlcdc/1.0/lestmtsref/n1rill4udj0tfun1fvce3j401plo.htm#n0tskm...

They are usually very good at replying.

Does the infile statement not get the correct data if the encoding is not specified?

[whymath]

Thanks, @ChrisNZ.

The link doesn't describe the pipe and encoding inssue, perhaps I have to ask my tech support.

pipe option actually pass the command, which is dir "&path." /b/s, to the terminal of operation system(CMD for Windows). However, CMD's results are encoded as ANSI, for me, that means EUC-CN. So I'm reading a EUC-CN encoded file in unicode enviroment and I can't specify the encoding option. There are a lot of garbled characters in the result.

[ChrisNZ]

> CMD's results are encoded as ANSI,

@whymath That's disappointing.

Have you try loading the correct codepage? UTF-8 is 65001 for example.

So you could try running something like

chcp 65001 & dir "&path" /b/s 

or

chcp 65001>nul & dir "&path" /b/s 

[Kurt_Bremser]

The issue may be documented in a quite veiled way:

(from the INFILE Statement)

ENCODING= 'encoding-value'

specifies the encoding to use when reading from the external file.

(emphasis by me)

This could indicate that ENCODING= can only be used with files, and not other device types.

Although I see no technical reason for this, as the combination of PIPE and ENCODING= works in a FILENAME statement:

filename test pipe "ls" encoding="WLATIN1";

data _null_;
infile test;
input;
put _infile_;
run;

filename test clear;

Which means that @whymath can simplify the code by moving the PIPE option to the FILENAME statement, thereby avoiding the creation of the external file.

[ChrisNZ]

Interesting @Kurt_Bremser . I did try that before replying and this fails on Win64 with 9.4M7.

So it might be that Unix behaves differently. All the more reason to ask Tech Support to sort this out, and to have the documentation amended.

[Kurt_Bremser]

It is definitely an OS issue, because this also works on AIX:

data _null_;
infile "ls" pipe encoding="WLATIN1";
input;
put _infile_;
run;

Just did not think of testing it earlier.

@whymath you should clearly check this with SAS technical support. If it is an issue with the way Windows handles pipes, then it should at least be documented.

In the Windows companion, there is only an error message documented when ENCODING= is used with CARDS or DATALINES.

[ChrisNZ]

This looks like a defect, it's very uncommon that such syntax is inconsistently supported across platforms.

[whymath]

I still get the same error when I run your first line of program.

This is my info of lab:
Version: SAS9.04.01M5

Machine: SAS-Win10-0029 X64_10PRO

Anything wrong?

[ChrisNZ]

@whymath It seems this only works on Unix, not on Windows.

Again, a good reason to seek clarification from tech support, and to request clarification of the doc.

[s_lassen]

The documentation for the FILENAME statement explicitly states:

Not all device types support the encoding option. For more information, see the documentation for your operating system.

But there is no mention of a limitation on using ENCODING= with the PIPE device type in the Windows documentation. There probably should be.

[ChrisNZ]

Indeed. And such support depending o the OS is rather unusual. So this might not have happened on purpose.

[Tom]

Did you try doing the transcoding yourself?

data test;
  infile "&path.\_dir_.txt" truncover ;
  input path $1024.;
  path=kcvt(path,'zeuc','utf-8');
run;