I'm trying to get xdg-open to using chromium to open urls instead of firefox. I noticed that xdg-settings get default-web-browser returns chromium.desktop when it should be chromium-browser-chromium.desktop.
Following the instructions here I tried xdg-settings set default-web-browser chromium-browser-chromium.desktop, which runs with no errors. However when I run xdg-settings get default-web-browser it stills shows chromium.desktop, and xdg-open "http://www.example.com" still uses firefox. I have confirmed that /usr/share/applications/chromium-browser-chromium.desktop is present. Rebooting the machine does not fix the problem.
For now, I've created a "chromium.desktop" sym-link to "chromium-browser-chromium.desktop", but it would be nice to know why xdg-settings is not working.
xdg-* utilities are just quite simple POSIX shell scripts that try their best to handle simple common DE tasks in a seemingly standardized way. But the truth is, that every DE uses its own tools and knobs, and every installation uses different mix of them, so in this case it seems that you're using some non-standard desktop environment, which these poor utilities just cannot handle.
Anyway, if you want to debug your specific issue, run those scripts with sh -vx (eg. sh -vx /usr/bin/xdg-settings) and it will tell you exactly what those scripts are doing and at which point they fail.
Related
I am making a public image on AWS and so am required to 'hide' some shell scripts, but still have them freely usable. We're not looking for the utmost security, I understand SHC can be reverted if a user actually wishes to do so, but it's enough for my requirement.
So that's all good! I have a shell, 'test.sh'. I convert it, 'shc -f test.sh'. The output is a .x and a .x.c file. I run './test.sh.x' - It runs exactly as I expect it to.
So far so good...
But if at any point I reboot the instance, then when I try and run './test.sh.x' again it fails and just outputs a load of random binary stuff.
I have absolutely zero idea what is causing this or why it is causing this. The file is not being edited, or moved, or anything.. It just suddenly does not work anymore. Why?? I've searched online but can't seem to find anyone having this same issue, so any help will be massively appreciated.
And to note, a valid alternative that may not result in the same issue (worth testing at least) is most welcome, as I'm not dead-set on using SHC specifically, it's just the only one I know about currently.
Oooookay, well I unfortunately was never able to fix this issue. Even if I install SHC after I create an instance from my own AMI, and then compile the scripts at this point, the scripts only work until I reboot the system and then they no longer work.
So instead I found a different solution using Bash-Obfuscator, installed and run as follows:
dnf -y install npm nodejs
npm install -g bash-obfuscate
bash-obfuscate test_input.sh -o test_output.sh
And that perfectly does what I needed. There was, however, one thing I quickly learned using Bash-Obfuscator which was quite important - Do NOT have 'echo' commands across multiple lines as it will break your script. The following will break when obfuscated using this command:
echo "Hello
World"
But replacing that with this (which is practically the same thing) works perfectly okay (must be some way the parser is coded):
TEST_VAR="Hello
World"
echo "${TEST_VAR}"
Hope this helps anyone in future.
It feels impossible to get it to run on any custom terminal. I know that octave-cli.app is there but it always opens in the standard terminal. Any ways to execute octave scripts like a compiler (or) run it interactively like an interpreter from Iterm?
Using Mac OSX 10.9+
Edit:
I know how to export path variables. But having searched the web can't find a way to do it. Is it even possible? I even tried it using homebrew to no avail.
You can see the content of octave-cli.app, it's a script. Mine goes like this
open -a Terminal.app /usr/local/octave/3.8.0/bin/octave | logger 2>&1
It specify the terminal application used to open octave. This is the reason of your problem, as I think.
The solution is linking octave-cli in system path, better locates at "/usr/local/bin". like
ln -s /usr/local/octave/3.8.0/bin/octave-cli /usr/local/bin/octave-cli
Finally, octave can be accessed via any terminal(like iTerm) or shell(bash, zsh) by just type "octave-cli" command, which will be searched in system path and found to executed directly.
I just realized that i cannot execute .sh scripts anymore on my debian.
It used to work fine. All .sh files are +x chmodded and used to work fine.
Suddenly, once i execute: ./test.sh system hangs.
I am able to stop this via ctrl+c, but script never executes.
Steps did so far was to restart my VPS.
Any ideas?
I am pretty sure shell scripts are still working on your machine, because if they weren't, you would not be able to complete any boot cycle.
If I suppose you are facing problems with your homemade scripts, then you should probably check your shebang line (#!/bin/sh for example) to see if anything unusual was used there.
New scripts are using a dispatcher to interpreters:
`#!/usr/bin/env bash` #lends you some flexibility on different systems
`#!/usr/bin/bash` #gives you explicit control on a given system of what executable is called
The difference between “#! /usr/bin/env bash” and “#! /usr/bin/bash”?
I have been given a personal profile on a linux project server running bash 3.2.15. Every time I run a command it echoes the text of the command to screen. This isn't a serious issue, but it bugs the crap out of me. I can't find any specific command in .profile or .bashrc that sets this up, and everything I find through google is how to enable it. Not how to disable it. Anybody got any ideas?
It sounds like debugging has been enabled (using set -x). You can disable it using set +x.
I have a "stock" xmonad install on Arch.
No changes to my xmonad.hs yet
I have installed dmenu.
It runs by alt-p, the default, and displays and filters as expected.
Chromium runs, but other items, like ranger, alsamixer or other tasks do not.
I am not finding anything anywhere about anyone having to do anything to get these items to run, nor anyone having any issues with doing so.
Surely, then, there is something wrong in my install.
my dmenu_run is as follows:
#!/bin/sh
dmenu_path | dmenu "$#" | ${SHELL:-"/bin/sh"} &
I would normally run terminology with bash or zsh. I have tried to alter the SHELL to /bin/bash, but to no avail.
Is there any other place I must look or items I should alter?
Such a shame as I am really liking xmonad so far, and want to get dmenu working before I start exploring xmonad.hs...
Thanks in advance
UPDATE: I have found the following
here over at Archwiki that involves changing dmenu_run and adding a .demenu_term in one's home. It seems to work, but still wonder if there was a more orthadox mechanism.
ranger and alsamixer are applications which run inside a terminal. Imagine (or try) to run ls via dmenu, where should the directory listing be printed to without a terminal?
You look for functionality which is provided either by prompt imported from XMonad.Prompt.Shell by using a convinient keybinding like
((modm .|. shiftMask, xK_c), prompt ("xterm" ++ " -e") greenXPConfig)
(described in the linked documentation) or shellPrompt where you execute
xterm -e alsamixer
or any other command, e.g.
feh path/to/image/you/want/to/open/now.jpg
instead of opening a terminal, running above with tailing & and exiting the terminal.