tomweber-sas
commented
7 months ago Looking at the other issue, I don't see any understanding of what was happening or any resolution. So, what you're describing is simply doing the following, just hangs at that point?
import saspy
sas = saspy.SASsession()
(hung)?Thanks for showing your config, that looks fine, and running that datastep - that was just to see what kind of SAS session was trying to be connected to. Can you try changing the 'prompt' : True to False in the SAS_config_options in your config file and see if that makes a difference? Prompt should work in a python shell, but I don't have any idea at the moment why it would just hang there. You're on the same linux machine, just a local linux SAS install, right?
Can you see what's happening with the processes from another os shell and see if SAS came up, or if either SAS or Python are consuming cpu or anything? Do you have a SAS config file where the log is redirected or something out of the ordinary like that? And, what do you mean when you said that trying to just run SAS the same way from a shell does the same thing and create the __STDERR__ file in my home directory? I don't know what that is, but make me wonder if you have some configuration (SAS configuration) that's causing this.
Not to say 'it works for me', just showing the same thing I think you're showing, which is as close as I can see:
tom64-7> python3
Python 3.9.12 (main, Apr 5 2022, 06:56:58)
[GCC 7.5.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import saspy
>>> sas = saspy.SASsession(cfgname='tdi'); sas
SAS Connection established. Subprocess id is 752851
Access Method = STDIO
SAS Config name = tdi
SAS Config file = /opt/tom/github/saspy/saspy/sascfg_personal.py
WORK Path = /usr/tmp/SAS_work13E7000B7CD3_tom64-7/
SAS Version = 9.04.01M8P01182023
SASPy Version = 5.4.4
Teach me SAS = False
Batch = False
Results = Pandas
SAS Session Encoding = utf-8
Python Encoding value = utf_8
SAS process Pid value = 752851
>>> sas.sascfg.SAScfg.tdi
{'saspath': '/tdi/mva-v940m8/usrlibsas/laxno/SASFoundation/9.4/bin/sas_u8', 'options': ['-encoding', 'utf8']}
>>>I don't know of anything that could be prompting, so I'm thinking it's something with your SAS configuration redirecting output or something, at the moment. Need more info on that.
Tom
weg-jr
Describe the bug I am having an issue very similar to issue #343 except I am using a terminal and have no autoexec. I am using sas9.4 and saspy 3.7.2 on python 3.11.5. As soon as I initialize a sas session using using saspy the terminal freezes like its trying to read text directly from the terminal keyboard with no other input. This happens when running python or in a script, both cases will halt the program and wait for keyboard input before continuing. The only way to escape this is to ctrl+c which gives the sas termination prompt and then crashes saspy. A __STDERR__ file then appears in my working directory. ctrl+d or submitting endsas; does not stop this connection.
If I run the sample sas call
directly from the terminal I get the same behavior, except submitting an endsas statement or using ctrl+d will terminate the session and create the __STDERR__ file in my home directory. This time the file contains the log of whatever I "ran" at the terminal prompt. the return code is 0 for these cases. and I dont see any other file in my working directory.
calling just sas -nodms will give me an interactive sas session.
My sascfg_personal file is pretty basic with only the STDIO connection that points to sas_en. I tried sas_u8 but it has the same behavior.
sascfg_personal:
To Reproduce ( indentifying locations edited with *** as appropriate, )
I'm putting the data null statement that you ask for from the other issue. I got it from running the sas command in the traceback directly. Again this doesnt return any output, I need to read the __STDERR__ log file.
Expected behavior I can establish a sas session and interact with it in python instead of having my terminal hijacked by the sas input prompt
Additional context One other potential issue occurs if I select cancel instead of terminate at the sas termination prompt after pressing ctrl+c. Might be an edge case, but we are already in the middle of a traceback so it probably doesn't matter much.