From: Tech-talk <tech-talk-bounces at aps.anl.gov>
On Behalf Of Leblanc, Gregory via Tech-talk
Sent: 05 May 2021 21:30
To: tech-talk at aps.anl.gov
Subject: RE: EPICS 7 base on WSL2
There’s clearly something up with my git checkout.
/EPICS/epics-base$ file README
README: ASCII text, with CRLF line terminators
I ran the checkout from within ubuntu by doing:
$ git clone --recursive
https://github.com/epics-base/epics-base.git
Since there’s no CentOS package for WSL, for the short term, at least, I ditched WSL and installed CentOS-8-Stream in a VMware virtual machine. That seems to have gotten me a couple of steps further, but I’m pretty sure
I’m missing something pretty straightforward.
At
https://docs.epics-controls.org/projects/how-tos/en/latest/getting-started/installation.html#test-epics
I see a segment that shows:
Open a new terminal (we call it nr. 2) and try the command line tools caget and caput. You will see something like
your prompt> caget temperature:water
Is that a new linux terminal? If so, I get the following:
$ caget temperature:water
Channel connect timed out: 'temperature:water' not found.
However, the > implies that this is an epics prompt, but there is no caget in the list of commands for softIoc. I’m sure it’s staring me in the face, but I can’t see it.
Greg
Hi Greg,
I tried it just now and it all built and ran OK with no changes. My dbd file also looks to be with the correct line endings
/mnt/c/devel/wsl-epics-base$ file dbd/softIoc.dbd
dbd/softIoc.dbd: ASCII text
So I think you are right that the issue is line endings. If you run file on the top epics base README what does it give? For me that is also:
/mnt/c/devel/wsl-epics-base$ file README
README: ASCII text
If yours mentions CRLF etc. did you do the checkout using git from WSL or with windows git? Is a git config file getting picked up from somewhere that sets the line endings incorrectly?
I think the dbd files get generated from a .pod file using perl. If the above README is the correct line endings, then I would assume the .pod files are too. Another possibility is then that the wrong perl program
is being picked up – Windows strawberry perl would add CRLF. If you type which perl in WSL does it look right?
Regards,
Freddie
Anybody tried running EPICS under WSL? I was just playing around, trying to decide if heading down the EPICS path makes sense for our lab.
I followed the docs at:
https://docs.epics-controls.org/projects/how-tos/en/latest/getting-started/installation.html
I had to edit the EpicsHostArch script to change the line endings from CRLF to LF (or was it vice-versa?). After that, the build went well. I tried to run softIoc to do a test, and got the following:
$ softIoc
Error: Invalid character 'c'
at or before "c" in file "/home/leblanc/EPICS/epics-base/bin/linux-x86_64/../../dbd/softIoc.dbd" line 1
Error: Invalid character 'a'
Error: Invalid character 'l'
Error: Invalid character 'c'
Error: Invalid character 'o'
Error: Invalid character 'u'
Error: Invalid character 't'
Error: Invalid character 'D'
Error: Invalid character 'O'
Error: Invalid character 'P'
Error: Invalid character 'T'
Error: syntax error
Error: Failed to load DBD file: /home/leblanc/EPICS/epics-base/bin/linux-x86_64/../../dbd/softIoc.dbd
At which point I decided that was enough for a Friday night. I wonder if it might also be line endings, since file reports:
$ file EPICS/epics-base/dbd/softIoc.dbd
EPICS/epics-base/dbd/softIoc.dbd: ASCII text, with CRLF, LF line terminators
Am I out to lunch, or is it worth a try next week?
Greg
--
Gregory Leblanc
Accelerator Engineer
Edwards Accelerator Lab - Ohio University
123 University Terrace
Athens, OH 45701
leblanc at ohio.edu
M: (401) 52-OUAL1 or (401) 526-8251
This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify
the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own
virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments
that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI.