Gnome 3 and .desktop files - What exactly does "Allow/Disallow lauching do"? - refresh

I know that when creating a .desktop file, one can set the metadata::trusted as true and false, in order to be able to launch the icon as an executable.
What is intriguing me however is the fact that:
When right-clicking on the .desktop file and "Allow launching" apparently the only thing it does is to set the metadata::trusted to true. The icon, however, changes, as expected, instantly to the icon described in the .desktop file Icon=.
However when setting the metadata::trusted to either false or true via command-line the icon doesn't seem to change its behavior
$ gio set android-studio.desktop metadata::trusted false
Once I refresh the Desktop manually (Alt + F2 >> restart) the environment refreshes and the icon turns to be executable again, BUT the whole environment is restarted.
So, What does exactly "Allow/Disallow launching" does after setting the metadata::trusted? How does it refresh the metadata in the .desktop itself without refreshing the whole Desktop?

Your question is exactly the same as what I'm looking for.
On Ubuntu 18.04 (GNOME 3.28):
dbus-launch gio set file.desktop "metadata::trusted" yes
and (although this is not quite what you need)
killall nautilus-desktop && nautilus-desktop & disown
Ubuntu 20.04 (GNOME 3.36):
dbus-launch gio set file.desktop "metadata::trusted" true
but no nautilus-desktop...
dbus-send --type=method_call --print-reply --dest=org.gnome.Shell /org/gnome/Shell org.gnome.Shell.Eval string:'global.reexec_self()'
or something like systemd*...
Look at this code:
https://gitlab.gnome.org/GNOME/nautilus/commit/1630f5348
and here search "trusted":
https://download.gnome.org/core/3.36/3.36.2/sources/
nautilus-3.36.2/src/nautilus-file-operations.c
nautilus-3.36.2/src/nautilus-mime-actions.c

It may turns out to be simpler.
From desktop-file-utils.
man desktop-file-install
For example:
desktop-file-install --mode=0755 --dir=$HOME/Desktop /path/to/source/file.desktop

Quiet interesting, I've used combination of the two previous answers in order to "Allow Launching" .desktop file located at my desktop within Kali Linux 2022 with GNOME Shell:
desktop-file-install --mode=0755 --dir=$HOME/Desktop ~/Desktop/Telegram.desktop
dbus-launch gio set ~/Desktop/Telegram.desktop "metadata::trusted" true
Note the order of the execution of the commands is important!
Here is similar topic at Ask Ubuntu: .desktop files - Allow launching - set this via CLI.
Also for these who are interested in here is How to install the latest version Telegram for Desktop via CLI which was the reason to searching for the current topic.

Related

oh-my-fish `omf: command not found` in WebStorm terminal emulator

I am using WebStorm 2017.1.3 on Fedora 25.
I have fish set up as my default shell and installed oh-my-fish so in
Terminal I see my git branch and other information by default. omf update runs as expected.
In the WebStorm terminal emulator I still get fish, but not omf:
user#host ~> omf
fish: omf: command not found...
I'm a noob fish and omf user, can anyone help?
Thanks.
I have fish set up as my default shell and installed oh-my-fish so in Terminal I see my git branch and other information by default.
Note that you don't need omf for this. Fish ships a number of prompts that include vcs information. You can pick one with fish_config or add the __fish_vcs_prompt function to your fish_prompt.
In the WebStorm terminal emulator I still get fish, but not omf:
user#host ~> omf
fish: omf: command not found...
The "omf" function is stored in a file named "omf.fish" in a directory in $fish_function_path. This means that directory isn't included there.
The way omf works in a reasonably current (> 2.3.0) fish is that it has a bootstrap file (~/.config/fish/conf.d/omf.fish) that then sources the rest. It seems this isn't run.
I'd suggest you compare the values of $fish_function_path, $OMF_PATH and possibly $XDG_DATA_HOME in webstorm and outside of it.
An answer was given here: IntelliJ's embedded terminal does not load fish functions. I.e, add some lines of code to the app for the time being (until Jetbrains makes a fix).
I fixed this by going to Settings | Terminal then turning off Shell integration.
This allowed me to run omf and also have the bobthefish theme work with powerline/nerd fonts (after updating the terminal font at Settings | Editor | Color Scheme | Font Console)
I was using phpStorm 2017.3.4 but I assume this will also work in any IntelliJ embedded terminal.

Launch a program at login without permissions (fedora 20)

I'm currently developing an application with QT 4.8 with a "Launch on login" option. My main problem currently is that I can't seem to find a proper way to make the program launch itself after login on Linux (Fedora 20 in my case).
My program should be able to run in the background without stopping fedora to launch.
I would also like to avoid having to ask for any sort of admin privilege since my application doesn't require any (except maybe for this option).
Finally found out about "home/.config/autostart/.desktop".
I'll have to create autostart if it's not created but from there I can chose to make or delete the file depending on what my user decided to do.
The .desktop file have to follow a particular syntax (which is not a problem for me)
[Desktop Entry]
Type=Application
Exec=</path/to/binary or command to execute>
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=<Name_to_be_displayed>
Comment=<optional comment>
In my case, I can just remove the "comment" line since just the name of the application should be enough for the user to recognize it.
You can Either keep your executable in side /etc/rc.d/rs or inside /etc/init.d folder, so that it can automatically start once device is up.
Hope this Helps.
Each user has a .bashrc file located in their home directory, you could append a command to run your application to the end of that.
That will run when only that user logs in (I think either with graphical or terminal session)
To run for all users, look at creating a systemd service if you dare, or append a line to the end of /etc/rc.local. You'll need to be root for that though.
EDIT: Don't forget to put an ampersand at the end of the command to run in background.

Child_info_fork error running code on cygwin [duplicate]

I recently reinstalled Cygwin on my computer in order to get access to several command line elements that I was missing. I have never had previous difficulty with Cygwin, but after this reinstallation, an error message continues to appear after (almost) each command entered. For instance:
-bash-4.1$ wc m1.txt
3 [main] bash 2216 child_info_fork::abort: data segment start: parent(0x26D000) != child(0x38D000)
-bash: fork: retry: Resource temporarily unavailable
2013930 4027950 74968256 m1.txt
Generally, the command still runs (as seen above), but not always. Occasionally, the 'error' message occurs several times in a row (the initial number "3" will then change to a "4" or "2", notably if I start a second Cygwin window.
Also, as soon as I start up Cygwin, I get the following message before the prompt:
3 [main] bash 6140 child_info_fork::abort: data segment start: parent(0x26D000) != child(0x36D000)
-bash: fork: retry: Resource temporarily unavailable
-bash: fork: Resource temporarily unavailable
-bash-4.1$
At the moment, I am debating whether to uninstall/reinstall Cygwin again or just live with the error messages, but I was curious if there might be an issue that I am unaware of.
(assuming Cygwin is installed at C:\Cygwin):
Open Task Manager and close any processes that look to be Cygwin related.
Open C:\Cygwin\bin in Windows Explorer
Verify that dash.exe, ash.exe, rebase.exe, and rebaseall exist in this folder
If any of them are missing, re-run Cygwin setup and select the dash, ash, and rebase packages
right-click your C:\Cygwin folder, uncheck Read-only (if its checked), and press OK.
When an error about not being able to switch some files comes up, select "Ignore All". Wait for this process to complete.
Browse to C:\Cygwin\bin in Windows Explorer
Right click dash.exe and click "Run as Administrator". A command Prompt should appear with nothing but a $
Type /usr/bin/rebaseall -v, hit enter, and wait for the process to complete.
If you get errors about Cygwin processes running, try Step 1 again. If that still doesn't work, Restart your computer into safe mode and try these steps again.
A commenter noted that, depending on your settings, you may have to type cd /usr/bin && ./rebaseall -v instead.
Try opening Cygwin again.
This process worked for me. I hope it works for you guys too.
Source: http://cygwin.wikia.com/wiki/Rebaseall
I would like to add the following to the above answers, as it is what I had to do after reinstalling Cygwin:
Navigate to the "/usr/bin" directory (usually, C:\cygwin\bin) and right click, Run as Administrator the file: dash.exe
Then, at the $ prompt type the following, hitting enter after each line:
cd /usr/bin/
/usr/bin/peflags * -d 1
/usr/bin/rebaseall -v
What it does is, it marks the dll's as "rebase-able," and then rebases them. You have to have peflags.exe in addition to the above files (in previous answers). You may have to restart windows after doing this and you will definitely need to make sure that there are no processes nor services belonging to cygwin running. (Use task manager, kill any related processes, and then under the services tab look for any service starting with CYG and stop it.)
After doing this, I was able to get cygwin to run without any errors about dll's being loaded to the wrong addresses aka fork errors, etc.
I hope that this helps others, as it was a pain to find.
SOURCE: http://www.cygwin.com/faq.html#faq.using.fixing-fork-failures
and the rebase README file.
To add on to other answers here, we ran into the same issue but could not run the rebase command from the ash or dash shell. However, when launching the command from the Windows cmd shell, the following worked.
cmd /c "C:\cygwin64\bin\ash.exe /usr/rebaseall -v"
-v is to get verbose output
I found another information here :
http://cygwin.com/ml/cygwin/2014-02/msg00531.html
You have to delete the database at
/etc/rebase.db* and do in a "ash" windows :
peflags * -d 1
rebaseall
It works for me on 2 servers.
I solved this problem by restarting my computer. Probably installed a driver update and kept using sleep instead of shutting down.
Experienced the same issue when loading Cygwin with cygiconv-2.dll forking and not loading successfully in the Cygwin terminal, but after turning off my AntiVirus (it was specifically Ad-aware), the issue resolved, and Cygwin worked properly.
In case you are using babun's Cygwin, after rebaseall, try launching Cygwin by executing .babun\cygwin\cygwin.bat in a Windows command prompt or Windows explorer.
This works for me (while launching babun's default console - mintty results in fork error).
I had the error on win10 and i was trying to rebase to c: before install.
then i saw that the installer was installing it instead to c:/Users/myuser
so i was coping all files from c:/Users/myuser to c:.badun
and then restart plus open badun.bat
not shure if this was wise its now duplicated XD... but then it worked again.
Rebaseing didn't help in my case. In addition to what other people suggested, I noticed that reducing the length of PATH environment variable fixed the issue for me (and for other people as well as can be seen from this answer).
This issue is intermittent in nature & I found this issue when there is network is too slow to connect to remote machine on AWS.... I have Shell script that runs through Gitbash shell & it connects to AWS EC2 instance with ssh..... Most of the time, it ran correctly but 2 out 100 times it get into this issue bash: fork: retry: Resource temporarily unavailable .... Killing the MSYS2 terminal from task manager helps to overcome with this issue....
Negative side is you need to run the scripts from the beginning...
I had the same issue on Windows 10 and the mobaxterm app (which uses cygwin) and I tried all of answers listed here however for me, the solution was to simply delete the "CryptoPro CSP" application.
I started facing this problem after upgrading to windows 10. As of now I do not see that any of the above method working.
What I am noticing is that if you start cygwin with admin right (right click and say "run as admin") then it works fine.
Or you open cmd as administrator and then launch cygwin from there, then also it runs fine.
Just reinstall cygwin and select TCL and activate EXPECT

How to create a Linux desktop icon cross desktop (KDE, GNOME) with xdg-desktop-icon?

I'd like to use the xdg-desktop-icon tool because it can be scripted and works cross desktop (at least on Linux with Gnome and KDE). At least it is supposed to do so according to freedesktop.org. 1
Made a minimal file: test.desktop
[Desktop Entry]
Encoding=UTF-8
Type=Application
Exec=test
Icon=test
Name=test
Used xdg-desktop-icon...
xdg-desktop-icon install --novendor test.desktop
Exit code is 0. (Success.) But... I do not see any new icons on my desktop. Also not after reboot. This failed on Ubuntu Precise 12.04 with KDE and on Debian Wheezy with KDE.
How to use the xdg-desktop-icon tool correctly?
The problem on KDE has something to do with the desktop settings. Folder view, Newspaper view and so on.
xdg-desktop-icon relies on xdg-user-dir to determine the user desktop directory. You can check either against that command and the settings of your file manager (or program handling the desktop).
Assuming by default it would be /home/user/Desktop, then you have to check the file name there. If the file is there, then xdg-desktop-icon is working as expected.
You have to consider that the icon (test in your case) has to be installed separately using xdg-icon-resource. That is, if you are not using a stock icon or custom icon already installed or you are not using an absolute path for the icon.
Do not forget that xdg-desktop-icon only copies the .desktop file in a specific directory. No more no less.
If I am working on ~/myapp directory, I would check by doing:
$ xdg-user-dir
/home/user/Desktop
$ ls `xdg-user-dir`/test.desktop
ls: cannot access /home/user/Desktop/test.desktop: No such file or directory
$ xdg-desktop-icon install --novendor test.desktop
$ ls `xdg-user-dir`/test.desktop
/home/user/Desktop/test.desktop
Eventually, you can run with any xdg- script with:
$ XDG_DEBUG_LEVEL=1 xdg-desktop-icon ...
Which will give you an extra line telling you where the desktop file was installed. At this point, if the icon has not been installed, it might appear an ugly default icon.

KDevelop debugging warning: Failed to set controlling terminal: Operation not permitted

A while ago I changed my personal operating system to linux and my development enviroment to KDevelop.
However debugging c++ projects is still not working as it should.
My KDevelop version is 4.2.2 (I installed it through package management)
Every time I hit the "debug button" the application is starting with the console message
warning: GDB: Failed to set controlling terminal: Operation not permitted and debugging functionality is not available.
Any ideas welcome.
(If you need additional information don't hesitate to ask)
I also had this problem, but I use gdb in KDevelop sparsely enough that hadn't bothered me yet. Here's my log of trying to fix it:
Grepping through the GDB 7.3.1 source code reveals that this message is printed when GDB tries to set its master TTY to a newly-created pseudo-tty (see gdb/inflow.c, lines 683-740). In particular, a call to ioctl with request TIOCSCTTY fails with a permissions error.
With this in mind, I took a look at the Linux kernel source code to see what could cause a failure. A bit of searching shows that it will eventually degenerate into a call to tiocsctty(). The comment from tiocsctty that is important here:
/*
* The process must be a session leader and
* not have a controlling tty already.
*/
Since the only other reason it can fail with EPERM is if the tty that GDB creates is actually a controlling tty for another process (which seems highly unlikely), I thought it reasonable to assume that GDB is not a session leader. Fair enough, it's launched by KDevelop after all!
So: I tried not launching the GDB session in an external terminal, and it works. Problem narrowed down.
Originally, the external terminal line was set to konsole --noclose --workdir %workdir -e %exe. Changing this to terminator -e %exe made a slight difference: KDevelop warned me that
GDB cannot use the tty* or pty* devices.
Check the settings on /dev/tty* and /dev/pty*
As root you may need to "chmod ug+rw" tty* and pty* devices and/or add the user to the tty group using "usermod -G tty username".
I checked my permissions; my user was part of the tty group and all relevant files were readable and writable.
Grepping through the KDevelop source code reveals how KDevelop actually sets up the terminal. It runs the shell script
tty > FIFO_PATH ; trap "" INT QUIT TSTP ; exec<&-; exec>&-; while :; do sleep 3600;done
and then sets up GDB to use the terminal device it reads from FIFO_PATH. (My name, by the way, not the one that KDevelop uses.) The problem (as best I can tell) is that gdb is not launched as a child of the shell script, and thus cannot use it as its main tty.
I'm not feeling up to patching KDevelop to make this work properly as of yet (or finding what actually caused this to stop working in the first place . . .), so the best I can suggest at the moment is to simply not use an external terminal for debugging purposes.
Good luck! I'll update if I find anything useful.
As Arthur Zennig said, for more information, you need to do something
Firstly, you need to create the Terminal profile
Secondly, open Launch Configurations, fill info such as the image below
Good luck!
In case you got the error:
"Can't receive konsole tty/pty. Check that konsole is actually a
terminal and that it accepts these arguments"
RUN > CONFIGURE LAUCHERS > (See picture below. My project name was "loops")
What worked for me was to uncheck checkbox "Use External Terminal". Found the in the "Compiled Binaries" Tab.