On 2017-06-13 22:47, Patrick Shanahan wrote:

* L A Walsh [06-13-17 15:36]:

...

Let me rephrase a previous Q --

When some program tries to show a URL, it invokes your "default browser". How does it know what your default browser is and where is that set?

Is it a symlink somewhere in your home directory, or a text file with the browser name in it? Or what?

not knowing what desktop you are using and knowing that it may be completely home-grown, in kde/plasma5 you set it with systemsettings5 --> applications --> default applications --> web browser

in xfce it is something similar but not systemsettings5.

But maybe it can be queried somehow across desktops. :-? -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

Op dinsdag 13 juni 2017 23:17:27 CEST schreef John Andersen:

On 06/13/2017 01:51 PM, Carlos E. R. wrote:

...

...

in xfce it is something similar but not systemsettings5.

But maybe it can be queried somehow across desktops. :-?

I would hope not.

Look, linda needs a single site solution. This doesn't have to be a world generic solution.

She can build and ship the entire command line or what ever she needs. The command line can query and environmental or use any number of means to accomplish this, even if it needs custom tweaks on each desk.

A 'grep -i browser ~/.config/*' results in kdeglobals:BrowserApplication=google-chrome.desktop which is ( on this machine ) the default browser. -- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 14 Jun 2017 00:20:26 +0200 "Carlos E. R." wrote:

On 2017-06-14 00:13, Knurpht - Gertjan Lettink wrote:

...

Op dinsdag 13 juni 2017 23:17:27 CEST schreef John Andersen:

...

On 06/13/2017 01:51 PM, Carlos E. R. wrote:

...

...

in xfce it is something similar but not systemsettings5.

But maybe it can be queried somehow across desktops. :-?

I would hope not.

Why not?

...

...

Look, linda needs a single site solution. This doesn't have to be a world generic solution.

It would help others.

...

...

She can build and ship the entire command line or what ever she needs. The command line can query and environmental or use any number of means to accomplish this, even if it needs custom tweaks on each desk.

A 'grep -i browser ~/.config/*' results in kdeglobals:BrowserApplication=google-chrome.desktop which is ( on this machine ) the default browser.

Here it finds nothing. I use XFCE, but KDE is also installed.

Here it finds nothing also - just a bunch of Is a directory errors. grep -ir shows lots of hits - too many for my terminal history to scroll back through. A lot of the hits seem to be due to chromium, which is NOT my default browser. So I think the technique requires some refinement. I run an LXDE desktop. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

L A Walsh composed on 2017-06-18 02:51 (UTC-0700): .

Says to execute firefox.desktop? Not firefox? . How does it get to firefox from firefox.desktop? . The "Exec=" line in the firefox.desktop file in /usr/share/applications, plus its environmental path. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-06-18 21:47, L A Walsh wrote:

Patrick Shanahan wrote:

---- This is the case where I'm not using a desktop, but am running a standalone X-application (like the LSI disk-management GUI that runs under X11). When I click on a link in an application (not under a desktop), it starts a browser on the ssh-target system and displays it via X on the ssh-source system, apparently using information from: ~/.local/share/applications/mimeapps.list )

To test the "xdg-open" command, I used google's search page which opened in the background. Nevertheless, in background, it used a bit over 9MB/s to display the animation on it's search page -- not a problem for me, but it does seem 80Mb/s might be a stretch for somebody on WiFI.

Interesting. I think that if you fire up firefox from inside ssh, it tries to run Firefox of the client machine, thus avoiding that B/W problem. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 2017-06-20 19:02, John Andersen wrote:

On 06/19/2017 03:48 AM, Carlos E. R. wrote:

...

Interesting.

I think that if you fire up firefox from inside ssh, it tries to run Firefox of the client machine, thus avoiding that B/W problem.

Carlos, I know you know better, so I'm assuming you somehow tangled uo that sentence. What was it you REALLY wanted to say.

I think you got two concepts conflated.

No, I did not.

ssh client is the (local) machine, where you sit. ssh server is the other (remote) machine where firefox runs.

X Server is the (local) machine, where you sit. X Client is the other (remote) machine, where you launched firefox.

No part of firefox runs on the local machine. You don't even have to have it installed locally.

Check it yourself. I did, and I insist: I get the local Firefox window, not the server machine Firefox. This is a known feature of firefox. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 06/20/2017 11:18 AM, Knurpht - Gertjan Lettink wrote:

Op dinsdag 20 juni 2017 20:04:26 CEST schreef Carlos E. R.:

...

On 2017-06-20 19:02, John Andersen wrote:

...

On 06/19/2017 03:48 AM, Carlos E. R. wrote:

...

Interesting.

I think that if you fire up firefox from inside ssh, it tries to run Firefox of the client machine, thus avoiding that B/W problem.

Carlos, I know you know better, so I'm assuming you somehow tangled uo that sentence. What was it you REALLY wanted to say.

I think you got two concepts conflated.

No, I did not.

...

ssh client is the (local) machine, where you sit. ssh server is the other (remote) machine where firefox runs.

X Server is the (local) machine, where you sit. X Client is the other (remote) machine, where you launched firefox.

No part of firefox runs on the local machine. You don't even have to have it installed locally.

Check it yourself.

I did, and I insist: I get the local Firefox window, not the server machine Firefox.

This is a known feature of firefox.

-Wrong, wrong, wrong. Firefox runs on the remote, X-forwarding sends the interface to the client. Easy to check: open an ssh -X session to the remote in one terminal window or tab, fire up firefox, open a second ssh session in a second window/tab . Next, run 'ps -ea| grep firefox' both locally and remotely. Solid proof.

It will take more to convince Carlos. I suggest he uninstall firefox locally. Hey its easy to reinstall. Then launch firefox in an ssh xterm from another machine. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/20/2017 01:25 PM, Carlos E. R. wrote:

On 2017-06-20 20:18, Knurpht - Gertjan Lettink wrote:

...

Op dinsdag 20 juni 2017 20:04:26 CEST schreef Carlos E. R.:

...

On 2017-06-20 19:02, John Andersen wrote:

...

On 06/19/2017 03:48 AM, Carlos E. R. wrote:

...

Interesting.

I think that if you fire up firefox from inside ssh, it tries to run Firefox of the client machine, thus avoiding that B/W problem.

Carlos, I know you know better, so I'm assuming you somehow tangled uo that sentence. What was it you REALLY wanted to say.

I think you got two concepts conflated.

No, I did not.

...

ssh client is the (local) machine, where you sit. ssh server is the other (remote) machine where firefox runs.

X Server is the (local) machine, where you sit. X Client is the other (remote) machine, where you launched firefox.

No part of firefox runs on the local machine. You don't even have to have it installed locally.

Check it yourself.

I did, and I insist: I get the local Firefox window, not the server machine Firefox.

This is a known feature of firefox.

-Wrong, wrong, wrong. Firefox runs on the remote, X-forwarding sends the interface to the client. Easy to check: open an ssh -X session to the remote in one terminal window or tab, fire up firefox, open a second ssh session in a second window/tab . Next, run 'ps -ea| grep firefox' both locally and remotely. > Solid proof.

You are wrong.

cer@Telcontar:~> ssh -X cer@Isengard.valinor Last login: Mon Jun 19 19:23:03 2017 from 192.168.1.14 Have a lot of fun... cer@Isengard:~> cer@Isengard:~> firefox cer@Isengard:~> ps afxu | grep -i firefox cer 21062 0.0 0.0 9328 1556 pts/12 S+ 22:23 0:00 \_ grep --color=auto -i firefox cer@Isengard:~> ps -ea | grep -i firefox cer@Isengard:~> cer@Telcontar:~> ps -ea | grep -i firefox 13546 ? 01:41:10 firefox cer@Telcontar:~>

QED.

The fact that your firefox command came immediatly back to a command prompt should have been a clue that you are NOT executing firefox. You've got something else in your path that starts and returns to a command prompt. run /usr/bin/firefox in your ssh terminal, or better yet run /usr/lib/firefox/firefox -- After all is said and done, more is said than done.

On 2017-06-20 22:59, John Andersen wrote:

On 06/20/2017 01:25 PM, Carlos E. R. wrote:

...

...

You are wrong.

cer@Telcontar:~> ssh -X cer@Isengard.valinor Last login: Mon Jun 19 19:23:03 2017 from 192.168.1.14 Have a lot of fun... cer@Isengard:~> cer@Isengard:~> firefox cer@Isengard:~> ps afxu | grep -i firefox cer 21062 0.0 0.0 9328 1556 pts/12 S+ 22:23 0:00 \_ grep --color=auto -i firefox cer@Isengard:~> ps -ea | grep -i firefox cer@Isengard:~> cer@Telcontar:~> ps -ea | grep -i firefox 13546 ? 01:41:10 firefox cer@Telcontar:~>

QED.

The fact that your firefox command came immediatly back to a command prompt should have been a clue that you are NOT executing firefox. You've got something else in your path that starts and returns to a command prompt.

Except by the fact that a firefox window pops up and displays "http://localhost" to my local Apache page where ssh client is running, not the one from the server.

run /usr/bin/firefox in your ssh terminal, or better yet run /usr/lib/firefox/firefox

cer@Telcontar:~> ssh -X cer@Isengard.valinor Last login: Tue Jun 20 20:01:32 2017 from 192.168.1.14 Have a lot of fun... cer@Isengard:~> which firefox /usr/bin/firefox cer@Isengard:~> rpm -qf /usr/bin/firefox MozillaFirefox-52.1.1-57.9.1.x86_64 cer@Isengard:~> /usr/bin/firefox cer@Isengard:~> ps -ea | grep -i firefox cer@Isengard:~> logout Connection to isengard.valinor closed. cer@Telcontar:~> ps -ea | grep -i firefox 26355 ? 00:09:40 firefox cer@Telcontar:~> And a firefox window opens locally. The one from the local machine, despite being called inside an ssh session to another machine. This has been this way since ever. There is a known switch to disable this feature. You find it, because it is documented. This Firefox window that opens displays in "file:///etc/hostname" Telcontar.valinor which is the local machine, the client machine. Why don't you give up and recognize the truth? You are simply wrong. It is absurd that you insist. But if you insist, I will shoot a video. Just tell me what command you want me to run to capture the video. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

* John Andersen [01-01-70 12:34]:

On 06/20/2017 07:00 PM, Carlos E. R. wrote:

...

Why don't you give up and recognize the truth?

It does NOT work that way for me. That's why.

I've tested on two different computers, one opensuse leap 42.2 the Other Manjaro.

Launching firefox and opening a file ALWAYS opens the file from the ssh server. It never opens the file from the ssh client.

I don't have two opensuse machines to test with to see if this is just some basdardized opensuse feature. Nobody else compiles it that way.

Would you like me to send you a movie Carlos?

to run the firefox instance on a remote opensuse machine: ssh to remove box firefox -no-remote opening /etc/hostname returns hostname of remote box -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Patrick Shanahan wrote:

* Patrick Shanahan [06-20-17 23:07]:

...

* John Andersen [01-01-70 12:34]:

...

On 06/20/2017 07:00 PM, Carlos E. R. wrote:

...

Why don't you give up and recognize the truth?

It does NOT work that way for me. That's why.

I've tested on two different computers, one opensuse leap 42.2 the Other Manjaro.

Launching firefox and opening a file ALWAYS opens the file from the ssh server. It never opens the file from the ssh client.

I don't have two opensuse machines to test with to see if this is just some basdardized opensuse feature. Nobody else compiles it that way.

Would you like me to send you a movie Carlos?

to run the firefox instance on a remote opensuse machine: ssh to remove box firefox -no-remote opening /etc/hostname returns hostname of remote box

this also works:

add

MOZ_NO_REMOTE=1 export MOZ_NO_REMOTE

to your profile.

Maybe John has that sort of stuff in his profile, that would explain why his setup reacts differently. I can only confirm the behaviour Carlos has described, even across widely varying openSUSE's. To get a remote firefox, I had to use '-no-remote' which gives me a much slower firefox, the host machine is also indicated in the windows title "Mozilla Firefox <@office34>". -- Per Jessen, Zürich (23.2°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/21/2017 04:09 AM, Carlos E. R. wrote:

...

Maybe John has that sort of stuff in his profile, that would explain why his setup reacts differently. I can only confirm the behaviour Carlos has described, even across widely varying openSUSE's. To get a remote firefox, I had to use '-no-remote' which gives me a much slower firefox, the host machine is also indicated in the windows title "Mozilla Firefox <@office34>". Exactly.

And it has been that way for ages. I found about this "feature" the first time I tried, expecting to get the server machine Firefox, and I had to ask here about this strange thing, and I was told that Firefox works that way, and to use "-no-remote" to disable.

I have no such settings in my profile, i've greped it, looked at firefox startup command lines, firefox profiles, etc. Can't find any such setting. I think there has to be more going on here than just a firefox setting. This sounds like a HUGE security flaw, if firefox can reach back across the ssh connection into my local machine, and feel around for an instance of itself (running or not) and launch it locally when I asked it to run remotely. There is something horribly broken about that. I'm glad it doesn't work for me. I'd be interested to see just what ssh options allow this, so that I can make a mental note never to turn them on. -- After all is said and done, more is said than done.

On 2017-06-22 01:12, L A Walsh wrote:

Carlos E. R. wrote:

...

Exactly.

And it has been that way for ages. I found about this "feature" the first time I tried, expecting to get the server machine Firefox, and I had to ask here about this strange thing, and I was told that Firefox works that way, and to use "-no-remote" to disable.

I've never seen this behavior.

Well, somehow that is not surprising. You customize a lot your systems, they depart too much from the standard. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

21.06.2017 19:20, Dave Howorth пишет:

It's not just opensuse. It behaves that way on Ubuntu and Scientific Linux as well. It also applies to different users on the same machine unless you isolate them with -no-remote.

Firefox looks for another instance on current X server. Normally only one user at a time has access to it so I would be surprised if it applied to different users by default. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Dave Howorth wrote:

On Wed, 21 Jun 2017 19:44:30 +0300 Andrei Borzenkov wrote:

...

21.06.2017 19:20, Dave Howorth пишет:

...

It's not just opensuse. It behaves that way on Ubuntu and Scientific Linux as well. It also applies to different users on the same machine unless you isolate them with -no-remote.

Firefox looks for another instance on current X server. Normally only one user at a time has access to it so I would be surprised if it applied to different users by default.

Just su to another user on a normal opensuse desktop and then try to open firefox.

--- That's different -- as it finds the firefox on the running machine. Carlos is claiming this works across machines -- something I've never seen. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 2017-06-22 01:13, L A Walsh wrote:

...

I've never seen this behavior.

Well, somehow that is not surprising. You customize a lot your systems, they depart too much from the standard.

--- Having a desktop running Windows, logging into a *nix machine isn't exactly what most people would classify as "customizing", though that I'm not running an X11 based browser on Windows _may_ be the reason I'm not seeing this behavior (I don't know of any X11 browsers that do run on Windows, offhand). Some of these crazy statements about what I run are baseless and often contrary to what is actually true. Just like someone from some suse list who thought I ran some "huge monolithic kernel" (no doubt trying to reference my, accurate, statements about sysd). It was also claimed I blamed sysd for every little problem: not only not true, but impossible as I don't run it. The _reality_ on the "huge monolithic kernel", with 8% of the loadable module total, built-in, my kernel was still 30% smaller than any of the kernels they were comparing it to. Too many people have misperceptions about my practices/setup that differ from reality which is unavoidable, but what is avoidable is them broadcasting those distortions to others causing no end of problems. You, Carlos, should know better.

...

That's different -- as it finds the firefox on the running machine.

Carlos is claiming this works across machines -- something I've never seen.

And we have proven that it is correct. I posted links to explanations and how it is done.

**remote control of unix mozilla**

[Borrowed from the 4.x x-remote doc]

--- The document(s) I can find about remote control (searching on your keywords) date back almost 10 years and don't mention firefox (ex.: https://www-archive.mozilla.org/unix/remote.html). It *seems* they may only be applicable to browsers run via X (which would exclude my Windows-based browsers).

«When Netscape Navigator is invoked with the -remote argument, it does not open a window, but instead connects to and controls an already-existing process. The argument to the -remote switch is an Xt action to invoke, with optional arguments.»

«Remote control is implemented using X properties, so the two processes need not be running on the same machine, and need not share a file system.»

What website did you get that from? I'd like to look at it -- who knows, I might be able to use a working X11 setup to do that to proxy commands into a non-X environment. (though it also might be too much work). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

Well, you did not say you were not using Linux. One, when posting here, assumes you are unless you say otherwise.

--- I am using linux where I want the redirection to occur. Trying to change where it is "coming from" (linux) by changing where it is going to (linux|windows) is a bit late, IMO.

From what I recall, you do customizations to not use initrd ram disk. That's a big modification. I have not said you use a "huge monolithic kernel".

Didn't say the kernel was about you, but where you boot from is big? Are you saying nature is more important than nurture, or is what about distro you've been raised with more important than a ram-based SSD vs. platters? If that question wasn't clear, you probably don't need to worry so much about where or how you were booted. If it is clear, you probably wouldn't be saying something like that. ;-) Are we clear yet? Which is bigger booting from memory (ram or SSD) or booting from ram vs. platters

It is not the case this time, it doesn't work for you because you are not using Linux on your client. Perhaps if you use Mobaxterm instead of Putty it would. Unsure.

Not using either. Cygwin uses 'ssh' over an xterm, which would work the same for me. Issue is how your browser displays, natively talking to a local hardware (on linux that'd be a direct-connect DRM which many desktops use to get cool effects, possibly, though rarely, routed through openGL). One of the main reasons I couple a windows desktop w/a linux backend is to get the best of both worlds. Windows, generally has faster and more flexible desktop SW, while Linux has better 'content/substance' hosting (files, network management, etc). -l -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-06-22 05:22, Andrei Borzenkov wrote:

21.06.2017 23:42, Dave Howorth пишет:

...

On Wed, 21 Jun 2017 19:44:30 +0300 Andrei Borzenkov wrote:

...

21.06.2017 19:20, Dave Howorth пишет:

...

It's not just opensuse. It behaves that way on Ubuntu and Scientific Linux as well. It also applies to different users on the same machine unless you isolate them with -no-remote.

Firefox looks for another instance on current X server. Normally only one user at a time has access to it so I would be surprised if it applied to different users by default.

Just su to another user on a normal opensuse desktop and then try to open firefox.

I get another firefox process running as another user.

Yes, so do I. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On Tue, 20 Jun 2017 13:59:53 -0700 John Andersen wrote:

On 06/20/2017 01:25 PM, Carlos E. R. wrote:

...

On 2017-06-20 20:18, Knurpht - Gertjan Lettink wrote:

...

Op dinsdag 20 juni 2017 20:04:26 CEST schreef Carlos E. R.:

...

On 2017-06-20 19:02, John Andersen wrote:

...

On 06/19/2017 03:48 AM, Carlos E. R. wrote:

...

Interesting.

I think that if you fire up firefox from inside ssh, it tries to run Firefox of the client machine, thus avoiding that B/W problem.

Carlos, I know you know better, so I'm assuming you somehow tangled uo that sentence. What was it you REALLY wanted to say.

I think you got two concepts conflated.

No, I did not.

...

ssh client is the (local) machine, where you sit. ssh server is the other (remote) machine where firefox runs.

X Server is the (local) machine, where you sit. X Client is the other (remote) machine, where you launched firefox.

No part of firefox runs on the local machine. You don't even have to have it installed locally.

Check it yourself.

I did, and I insist: I get the local Firefox window, not the server machine Firefox.

This is a known feature of firefox.

-Wrong, wrong, wrong. Firefox runs on the remote, X-forwarding sends the interface to the client. Easy to check: open an ssh -X session to the remote in one terminal window or tab, fire up firefox, open a second ssh session in a second window/tab . Next, run 'ps -ea| grep firefox' both locally and remotely. > Solid proof.

You are wrong.

cer@Telcontar:~> ssh -X cer@Isengard.valinor Last login: Mon Jun 19 19:23:03 2017 from 192.168.1.14 Have a lot of fun... cer@Isengard:~> cer@Isengard:~> firefox cer@Isengard:~> ps afxu | grep -i firefox cer 21062 0.0 0.0 9328 1556 pts/12 S+ 22:23 0:00 \_ grep --color=auto -i firefox cer@Isengard:~> ps -ea | grep -i firefox cer@Isengard:~> cer@Telcontar:~> ps -ea | grep -i firefox 13546 ? 01:41:10 firefox cer@Telcontar:~>

QED.

The fact that your firefox command came immediatly back to a command prompt should have been a clue that you are NOT executing firefox. You've got something else in your path that starts and returns to a command prompt.

I'm surprised that you haven't apparently tried this yourself, since indeed /usr/bin/firefox does return immediately! It's a symlink to a shell script that executes the binary if necessary. Firefox also does use a running process on the local machine as Carlos says. That's why it has the option -no-remote available which can suppress the bahaviour and make it use a new copy. See http://www-archive.mozilla.org/unix/remote.html

run /usr/bin/firefox in your ssh terminal, or better yet run /usr/lib/firefox/firefox

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 21 Jun 2017 10:40:26 -0700 John Andersen wrote:

On 06/21/2017 09:17 AM, Dave Howorth wrote:

...

I'm surprised that you haven't apparently tried this yourself,

If you are going to jump into threads late, you should perhaps read the whole thread before rushing to reply.

But no actual disagreement with my substantive comment then? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

22.06.2017 05:05, John Andersen пишет:

On 06/21/2017 01:43 PM, Dave Howorth wrote:

...

But no actual disagreement with my substantive comment then? You had no substantive comment, because, as I had already pointed out I did try it, and it does not work that way for me. And further, if Carlos didn't have Firefox already working on the ssh client machine it wouldn't work that way for him either.

It also wouldn't work for him if he cared enough about security to turn off ForwardX11Trusted yes in his /etc/ssh/ssh_config.

Could you elaborate? I do not see any immediate difference between using "ssh -X" and "ssh -Y" related to this discussion. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

John Andersen wrote:

On 06/21/2017 01:43 PM, Dave Howorth wrote:

...

But no actual disagreement with my substantive comment then? You had no substantive comment, because, as I had already pointed out I did try it, and it does not work that way for me. And further, if Carlos didn't have Firefox already working on the ssh client machine it wouldn't work that way for him either.

It also wouldn't work for him if he cared enough about security to turn off ForwardX11Trusted yes in his /etc/ssh/ssh_config.

It's the openSUSE default. I guess you changed yours. -- Per Jessen, Zürich (23.5°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

20.06.2017 23:25, Carlos E. R. пишет:

On 2017-06-20 20:18, Knurpht - Gertjan Lettink wrote:

...

Op dinsdag 20 juni 2017 20:04:26 CEST schreef Carlos E. R.:

...

On 2017-06-20 19:02, John Andersen wrote:

...

On 06/19/2017 03:48 AM, Carlos E. R. wrote:

...

Interesting.

I think that if you fire up firefox from inside ssh, it tries to run Firefox of the client machine, thus avoiding that B/W problem.

Carlos, I know you know better, so I'm assuming you somehow tangled uo that sentence. What was it you REALLY wanted to say.

I think you got two concepts conflated.

No, I did not.

...

ssh client is the (local) machine, where you sit. ssh server is the other (remote) machine where firefox runs.

X Server is the (local) machine, where you sit. X Client is the other (remote) machine, where you launched firefox.

No part of firefox runs on the local machine. You don't even have to have it installed locally.

Check it yourself.

I did, and I insist: I get the local Firefox window, not the server machine Firefox.

This is a known feature of firefox.

-Wrong, wrong, wrong. Firefox runs on the remote, X-forwarding sends the interface to the client. Easy to check: open an ssh -X session to the remote in one terminal window or tab, fire up firefox, open a second ssh session in a second window/tab . Next, run 'ps -ea| grep firefox' both locally and remotely. > Solid proof.

You are wrong.

cer@Telcontar:~> ssh -X cer@Isengard.valinor Last login: Mon Jun 19 19:23:03 2017 from 192.168.1.14 Have a lot of fun... cer@Isengard:~> cer@Isengard:~> firefox cer@Isengard:~> ps afxu | grep -i firefox cer 21062 0.0 0.0 9328 1556 pts/12 S+ 22:23 0:00 \_ grep --color=auto -i firefox cer@Isengard:~> ps -ea | grep -i firefox cer@Isengard:~> cer@Telcontar:~> ps -ea | grep -i firefox 13546 ? 01:41:10 firefox

This one has consumed almost two hours of CPU time, so it obviously cannot be the one you just started. Your command does not start new firefox, it causes already running firefox to open URL in new window. This is subtle difference. https://askubuntu.com/questions/3515/how-do-i-launch-a-remote-firefox-window... Try killing all local firefox processes and try once more. Hmm ... if you start the first instance remotely, then I'd expect that starting *local* firefox would attempt to forward request to remote instance ... it becomes amusing :)

On 2017-06-21 05:20, Andrei Borzenkov wrote:

20.06.2017 23:25, Carlos E. R. пишет:

...

cer@Telcontar:~> ssh -X cer@Isengard.valinor Last login: Mon Jun 19 19:23:03 2017 from 192.168.1.14 Have a lot of fun... cer@Isengard:~> cer@Isengard:~> firefox cer@Isengard:~> ps afxu | grep -i firefox cer 21062 0.0 0.0 9328 1556 pts/12 S+ 22:23 0:00 \_ grep --color=auto -i firefox cer@Isengard:~> ps -ea | grep -i firefox cer@Isengard:~> cer@Telcontar:~> ps -ea | grep -i firefox 13546 ? 01:41:10 firefox

This one has consumed almost two hours of CPU time, so it obviously cannot be the one you just started.

Your command does not start new firefox, it causes already running firefox to open URL in new window. This is subtle difference.

Correct :-) It also happens when you call firefox from a local terminal.

https://askubuntu.com/questions/3515/how-do-i-launch-a-remote-firefox-window...

https://lists.opensuse.org/opensuse/2010-12/msg00315.html http://www-archive.mozilla.org/unix/remote.html

Try killing all local firefox processes and try once more.

In that case it starts a remote firefox.

Hmm ... if you start the first instance remotely, then I'd expect that starting *local* firefox would attempt to forward request to remote instance ... it becomes amusing :)

I haven't tried that one. But yes, there are some amusing consequences. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 2017-06-20 22:26, Patrick Shanahan wrote:

* Knurpht - Gertjan Lettink [06-20-17 14:20]:

...

Op dinsdag 20 juni 2017 20:04:26 CEST schreef Carlos E. R.:

...

On 2017-06-20 19:02, John Andersen wrote:

...

On 06/19/2017 03:48 AM, Carlos E. R. wrote:

...

Interesting.

I think that if you fire up firefox from inside ssh, it tries to run Firefox of the client machine, thus avoiding that B/W problem.

Carlos, I know you know better, so I'm assuming you somehow tangled uo that sentence. What was it you REALLY wanted to say.

I think you got two concepts conflated.

No, I did not.

...

ssh client is the (local) machine, where you sit. ssh server is the other (remote) machine where firefox runs.

X Server is the (local) machine, where you sit. X Client is the other (remote) machine, where you launched firefox.

No part of firefox runs on the local machine. You don't even have to have it installed locally.

Check it yourself.

I did, and I insist: I get the local Firefox window, not the server machine Firefox.

This is a known feature of firefox.

-Wrong, wrong, wrong. Firefox runs on the remote, X-forwarding sends the interface to the client. Easy to check: open an ssh -X session to the remote in one terminal window or tab, fire up firefox, open a second ssh session in a second window/tab . Next, run 'ps -ea| grep firefox' both locally and remotely. Solid proof.

better recheck yer woopie stick. open firefox on a remote ssh connection and then try: file:///

Oh, I know for certain because the machines have a different home page, so I know which firefox is running. As you say, try file:/// or http://localhost. It is not the remote one. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

* Basil Chupin [06-20-17 23:32]:

On 21/06/17 06:26, Patrick Shanahan wrote:

...

* Knurpht - Gertjan Lettink [06-20-17 14:20]: [pruned]

...

...

-Wrong, wrong, wrong. Firefox runs on the remote, X-forwarding sends the interface to the client. Easy to check: open an ssh -X session to the remote in one terminal window or tab, fire up firefox, open a second ssh session in a second window/tab . Next, run 'ps -ea| grep firefox' both locally and remotely. Solid proof.

better recheck yer woopie stick. open firefox on a remote ssh connection and then try: file:///

Patrick, what's a "woopie stick", please?

the big hammer you were born with :) -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 2017-06-20 19:02, John Andersen wrote:

...

On 06/19/2017 03:48 AM, Carlos E. R. wrote:

...

Interesting.

I think that if you fire up firefox from inside ssh, it tries to run Firefox of the client machine, thus avoiding that B/W problem.

Carlos, I know you know better, so I'm assuming you somehow tangled uo that sentence. What was it you REALLY wanted to say.

I think you got two concepts conflated.

No, I did not.

...

ssh client is the (local) machine, where you sit. ssh server is the other (remote) machine where firefox runs.

X Server is the (local) machine, where you sit. X Client is the other (remote) machine, where you launched firefox.

No part of firefox runs on the local machine. You don't even have to have it installed locally.

Check it yourself.

I did, and I insist: I get the local Firefox window, not the server machine Firefox.

I agree with Carlos, this is also the behaviour I see. -- Per Jessen, Zürich (23.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-06-22 01:17, L A Walsh wrote:

Per Jessen wrote:

...

...

Check it yourself.

I did, and I insist: I get the local Firefox window, not the server machine Firefox.

I agree with Carlos, this is also the behaviour I see.

Well cripes -- I've never seen that behavior.

How does the remote end contact the browser locally and pass it a URL?

Read the links we posted to Mozilla documentation. The feature goes back to Netscape 4. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On 06/13/2017 06:46 PM, Carlos E. R. wrote:

I knew it! I knew it! :-)

I mean, I knew there must be a desktop independent way. Thank you! :-)))

Let's try it.

cer@Telcontar:~> xdg-settings get default-web-browser cer@Telcontar:~>

Oops.

cer@Isengard:~> xdg-settings get default-web-browser cer@Isengard:~>

Oops. Does not work on my two computers that are running this instant. Sigh...

But what happens when you just do: xdg-open 'http://www.freedesktop.org/' Does that work? -- After all is said and done, more is said than done.

On 2017-06-14 03:50, John Andersen wrote:

On 06/13/2017 06:46 PM, Carlos E. R. wrote:

...

I knew it! I knew it! :-)

I mean, I knew there must be a desktop independent way. Thank you! :-)))

Let's try it.

cer@Telcontar:~> xdg-settings get default-web-browser cer@Telcontar:~>

Oops.

cer@Isengard:~> xdg-settings get default-web-browser cer@Isengard:~>

Oops. Does not work on my two computers that are running this instant. Sigh...

But what happens when you just do: xdg-open 'http://www.freedesktop.org/'

Does that work?

Yes. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

On Wed, 14 Jun 2017 03:46:09 +0200 "Carlos E. R." wrote:

On 2017-06-14 03:39, Anton Aylward wrote:

...

...

xdg-settings get default-web-browser firefox

WOW. And that works regardless of the DM I'm using. WOW!

I knew it! I knew it! :-)

I mean, I knew there must be a desktop independent way. Thank you! :-)))

Let's try it.

cer@Telcontar:~> xdg-settings get default-web-browser cer@Telcontar:~>

Oops.

cer@Isengard:~> xdg-settings get default-web-browser cer@Isengard:~>

Oops. Does not work on my two computers that are running this instant. Sigh...

Here: $ xdg-settings get default-web-browser firefox.desktop ??? But I do think Anton is correct about the intended mechanism. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 18/06/17 06:06 AM, L A Walsh wrote:

That works on my system to bring up FF on my linbox... So where does xdg-open look

Worst case: strace xdg-open .... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org