never good 
is clip in the PATH variable ?
@fpy Clip is the system command line utility for dumping output into the clipboard. It would be strange if it weren’t in the PATH. %SystemRoot%\system32 is in the PATH, and clip is in that directory, so clip is in the PATH. I can confirm that that by typing “clip /?” in the console and reading the help message. Or I can type “dir | clip” and see the contents of the directory in the clipboard.
I probably should have posted this originally. To demonstrate, type
Echo some text
into notepad & save it as foo.cmd. Type
<path>\foo.cmd | clip
into the cmd console & run it. If you check, you’ll see that the text is now in the clipboard.
In LO Basic, run the Shell function w/
Shell("<path>\foo.cmd | clip", 2,,True)
It runs but the output doesn’t show up in the clipboard.
Again, run the Shell function w/
Shell("cmd.exe /C ""<path>\foo.cmd | clip""", 2,,True)
It runs but the output doesn’t show up in the clipboard.
I did test “> test.txt” in place of “| clip”, & that works. So apparently it’s not all redirection, but only the pipe that doesn’t seem to work in Shell.
@fcsw again: what is »foo.exe« supposed to do, and why do you think its output needs to pushed into clipboard?
In my case, foo.exe sends http pings to a web site & returns the results. Grabbing the output from the clipboard is more convenient & faster than processing a text file containing the output.
so we come closer:
from subprocess import run
google_ping = run(["ping",'-c8', "8.8.8.8"], capture_output=True)
output = google_ping.stdout.decode('utf8')
print(output)
###
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=61.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=113 time=117 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=113 time=37.8 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=113 time=64.3 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=113 time=170 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=113 time=51.6 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=113 time=134 ms
--- 8.8.8.8 ping statistics ---
8 packets transmitted, 7 received, 12.5% packet loss, time 7012ms
rtt min/avg/max/mdev = 37.840/90.887/170.155/45.789 ms
###
1 Like
… and more problematic. Any concurrent interaction with the shared system resource, which clipboard is, will break your program flow. You (and users of your program) won’t be allowed to copypaste during its execution.
@karolus I appreciate the effort, but I said foo was running http pings, not icmp pings. In this case, an http ping is basically a HEAD request, which doesn’t put much burden on the web server but returns a status code; e.g. 302 redirected.
I don’t recognize the programming language. It’s been a long time since I coded in anything but Basic.
@mikekaganski
Yep. It will require code that checks the contents of the clipboard before processing it. There’s no perfect solution here. If the clipboard turns out to be too unreliable, it won’t be the first unsuccessful experiment I’ve made since I started this project. It’s the nature of programming that not everything works as well as the programmer thinks it will.
thats fine, so you dont need subprocess anymore, but some simple http-request, which can be done by python!
import urllib.request
with urllib.request.urlopen("https://www.google.com/") as g:
out = g.status
print(out)
###
200
as already said 16 hours ago:
Apparently I was right.
wow, marvelous tautology : you’re not using python, so you must use python 
or only clip ?
on my linux box, both work :
Shell("bash -c ""date > /tmp/xx"" ", 2,,True)
Shell("bash -c ""date | tee /tmp/xx"" ", 2,,True)
$ cat /tmp/xx
Fri Aug 29 08:58:42 AM CEST 2025
Fri Aug 29 08:58:42 AM CEST 2025
@fpy YOU and @fcsw MUST not! you may continue playing around obfuscated shell -command-strings
but unfortunatly @fcsw OS is not a linux box!
just pretty standard (since the 70’s)
indeed.
apparantely I was right
It’s great that you’ve been working with shell commands since the 1970s! You have my respect for that!
Otherwise, I also like to do a lot in the terminal, but I would never try to execute these commands from basic via shell aslong I know that there is a more robust way to do so!
not that I’m looking for or needing it, but thanks for mentioning;
you also deserve my and our respect for all your positive contributions in general.
authority answer doesn’t make it right,
and XY problem is not about just robustness impressionism.
IMHO, this site is about sharing, not just dogmatism
if there are known bugs with Shell(), we should try to log and solve them;
nothing major at first glance …
153719 – 7.5 BASIC shell function fails (flatpak and snap versions)
yes… In this case, dogmatism is insisting on using “shell” because you absolutely want to continue working with “basic.”
Why are you trying to delegate this work to others?
Do it yourself!
I’m certainly not going to try to track down and fix all the side effects of “basic … shell” in the context of container formats such as (spap, flatpak, and appimages)!
you may need to double check the title of this topic ;
or go enjoy, there plenty of others to hijack : Topics tagged basic
weird twist 
That was a good question. I ran
Shell("cmd /C ""type " & strPath & "\test.txt | find /I """"returns"""" > " & strPath & "output.txt""", 2,, True)
and the lines in test.txt containing “returns” showed up in output.txt. So it seems like Shell has a problem with clip, but not w/ the pipe.
I selected my own post as the solution because it answers the original question. But the credit should go to @fpy for asking the critical question.
For the larger question of how to make Http HEAD requests, a python library could be embedded in the document, which would be superior to using external files. But the code in the LO documentation that explains how to access python scripts in Basic doesn’t work & it’s not obvious how to fix it. Code I’ve seen elsewhere also doesn’t work. Alternately, someone at the OO forum has posted Basic routines that use UNO to make Http requests, w/ no external code libraries. But it also doesn’t work, at least not on my computer. & finally there’s the OAuth2OOo extension. I haven’t tried it yet. Assuming it works, it requires an external file, which is still superior to my original solution requiring 2 external files. Also, it gives me more control over the Http requests.
While I was typing this, I discovered that I can run curl in cmd. But we’ve established that Shell doesn’t like clip, so yet another solution w/ problems.
you may find this one more inspiring : A funny observation related to the connection object
probably a side effect to explore :
Shell Function > 
Parameter Windowstyle is only effective on Windows systems…
further testing