All of a sudden, my wget installation started talking to me in Italian (when I do --help or in other interactions). I can understand it, but I have everything set in English and I'd prefer to keep that language. Any idea what's going on.
I'm under macOS 10.13.4 and I've wget 1.19.5 installed via Homebrew.
The problem occurs only with a couple of admin users, when I run it under my regular user, it keeps speaking English.
locale output seems fine.
Answering myself: As Basile Starynkevitch suggested, I used the printenv command to see that the LANG variable is unset and that Italian is taken as default in such a case. so I just put export LANG=en_GB.UTF-8 in my /etc/profile (actually in a script under /etc/profile.d). I've no idea why all of a sudden it takes such a default. My system is configured as English with Italian keyboard layout.
The same problem here. (wget respondes in german)
In my case - deleting the secondary language (which was in my case german) from
System-Preferences->Language and Region->Preferend Language
seems to solve the problem. (There is now a single ''English'' entry).
Related
I installed ghcup and:
Stack 2.9.1
HLS 1.8.0
cabal 3.6.2
GHC 9.2.5
All of them are the recommended versions(I verified it using ghcup tui). Then I installed the Haskell extension in VSCode. Unfortunately, it doesn't work. I get syntax highlighting (from the Haskell Syntax Highlighting extension, which seems to be automatically installed alongside the Haskell extension) but there is no Intellisense, no code completion, no error detection and no interactive mode (-->>> evaluation). I experimented with different folders and haskell files. The filetype is correct, because every time I open a .hs file, the Haskell extension checks for updates. I even installed Codium, because I suspected a fault in VSCode, but it was the same there as well.
The hsl language server doesn't seem to be working in Neovim, either. I uninstalled ghcup (ghcup nuke) and reinstalled again. The result is exactly the same. I prepended the PATH and chose vanilla and non-vanilla Stack integration in either installations.
Am I doing something wrong?
OS: Linux Mint on Ubuntu 20.04.1, kernel 5.15.0-56.
After around 10 tries, I managed to fix the problem. It turned out I had three problems:
I had only 12 GB free on my Linux partition, but it seems more are needed. I realised it, when it turned out some haskell-language-server files were missing. I enlarged my Linux partition (something I should have done months ago). The new installation installed all files
The Haskell Language Server HLS was not added to the PATH. I solved it by putting this snippet in ~/.ghcup/config.yaml:
"haskell.serverEnvironment": {
"PATH": "${HOME}/.ghcup/bin:$PATH"
}
The server was now discovered by the Haskell VS Code extension but crashed 5 times and gave up on trying. Restarting it manually didn't help. I opened the logs: View->Output->Haskell and saw the error:
haskell-language-server-wrapper: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by haskell-language-server-wrapper)
It turns out, my Linux Mint distribution uses GLIBC_2.31, not 2.32. This is a very important library, which most applications on the system use. If you are a newbie, it is strongly advised that you DO NOT update it manually.
Instead, what I did, was install a version of the HLS, which used GLIBC_2.31. This problem occured in September and was "fixed" but apparently not very well. There are two options:
download the HLS deb10 version manually (didn't work for me):
ghcup install hls -u https://downloads.haskell.org/~hls/haskell-language-server-1.8.0.0/h
download using ghcup tui HLS version 1.7.0.0 (or whatever newest, which uses your glibc version) and a GHC, which supports that particular version of the HLS (in my case 9.0.2).
I think it's a good idea to preemptively reinstall the extension, in case it used the PATH to configure the HLS, so that its settings are restored to default. It takes up to 20 seconds to initialize the server, so be patient. You can see what's happening in the Output window and verify there are no more errors.
I hope this helps.
Currently I get this error
(file-error \"File cannot be opened\" \"Operation not permitted\" \"/Users/foo/Downloads\")")
In other answers I've seen we give ruby all the permissions as described here https://apple.stackexchange.com/questions/371888/restore-access-to-file-system-for-emacs-on-macos-catalina/371945#371945
but is this still the case? Is there an alternative? I am on Emacs 27.2
Since it's hard to control the app permissions for a specific directory on macOS (you can't add it in settings, and it only prompts on first access or something I'm not sure about), I recommend enabling Full Disk Access permissions for Emacs.
Another option to try is to reset the app Privacy and then confirm it the next time you are prompted (to access files in the Downloads folder).
# codesign --force --deep --sign - /Applications/Emacs.app
sudo tccutil reset All org.gnu.Emacs
Sounds like emacsformacos.
That is using a wrapper in ruby to decide which binary to run.
As nobody wants to give ruby full control I compiled it myself for some time.
With 28.1 I switched to
port install emacs-mac-app
Yesterday, after Ubuntu (or maybe Dell) installed some updates and I restarted, my snap applications were not showing on my sidebar, nor are they present in "show applications" or a normal search.
They are still installed and snap list still shows them, and they will still run via snap run <application>.
I've tried uninstalling them all (although I did not use --purge when I ran snap remove <application>), followed by uninstalling snap itself, then re-installing everything. They are still present but not showing up.
More searching has brought me to sites referencing the XDG_DATA_DIRS environment variable (explained HERE). If I understand correctly this should link all the folders where applications are stored, and the paths within should be separated by colons, not spaces. Thus I ran echo $XDG_DATA_DIRS and was rewarded with:
/usr/local/share/:/usr/share/:/var/lib/snapd/desktop /var/lib/snapd/desktop /var/lib/snapd/desktop
So I suspect my issue is the facts that the snapd directory is listed three times, and it is separated by spaces.
Does anyone have any ideas how I could fix this? I suspect, but am not certain that this is the issue.
I'm on Ubuntu 20.04, using fish shell.
I've found THIS post showing a possible solution, and upon running sudo ag "XDG_DATA_DIRS=" / 2>/dev/null | grep -v snap (and waiting a while) I got the following output (minus a few auth.log references which I've removed) Apologies for the big, possibly irreverent, "data dump"
/etc/profile.d/xdg_dirs_desktop_session.sh:4:DEFAULT_XDG_DATA_DIRS='/usr/local/share/:/usr/share/'
/etc/profile.d/xdg_dirs_desktop_session.sh:18: XDG_DATA_DIRS="$DEFAULT_XDG_DATA_DIRS"
/etc/profile.d/xdg_dirs_desktop_session.sh:21: XDG_DATA_DIRS=/usr/share/"$DESKTOP_SESSION":"$XDG_DATA_DIRS"
/etc/profile.d/apps-bin-path.sh:12: export XDG_DATA_DIRS="/usr/local/share:/usr/share"
/etc/X11/Xsession.d/55gnome-session_gnomerc:17: XDG_DATA_DIRS=/usr/share/gnome:/usr/local/share/:/usr/share/
/etc/X11/Xsession.d/55gnome-session_gnomerc:19: XDG_DATA_DIRS=/usr/share/gnome:"$XDG_DATA_DIRS"
/etc/X11/Xsession.d/60x11-common_xdg_path:5:DEFAULT_XDG_DATA_DIRS='/usr/local/share/:/usr/share/'
/etc/X11/Xsession.d/60x11-common_xdg_path:17: XDG_DATA_DIRS="$DEFAULT_XDG_DATA_DIRS"
/etc/X11/Xsession.d/60x11-common_xdg_path:20: XDG_DATA_DIRS=/usr/share/"$DESKTOP_SESSION":"$XDG_DATA_DIRS"
/usr/share/doc/gnome-software/README.md:24:$ XDG_DATA_DIRS=install/share:$XDG_DATA_DIRS ./install/bin/gnome-software
I'm not certain I have found the correct places to think about updating the environment variable, as none of these referenced /var/lib/snaped/desktop...And this might not be the issue causing the problem at all! Any help would be welcome!
You are running into https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1957948 which will require a fix in snapd.
Using a different shell as your login shell, and then executing fish once it has started, is the right workaround.
I am also having the same problem (suddenly Firefox disappeared in Gnome Shell) and I'm using Ubuntu 21.10 with fish shell. And just like you I could not figure out what caused this XDG_DATA_DIRS modification with the separation by spaces. Because you apparently also use fish I tried switching back to bash as login shell (chsh -s /bin/bash), rebooted and voila, the desktop files are loaded again. After that I set fish as the command to start with in gnome-terminal.
TLDR: My quickfix/workaround was chsh -s /bin/bash to switch to bash as login shell (instead of fish) and reboot.
After following Zanchy's links and reading around the issue I found the solution here!!!
I needed to replace
set XDG_DATA_DIRS $XDG_DATA_DIRS $snap_xdg_path
with
set XDG_DATA_DIRS $XDG_DATA_DIRS:$snap_xdg_path
in /usr/share/fish/vendor_conf.d/snapd.fish
Update: After another update I found my snaped.fish file had reverted, and I needed to edit it again - so this solution may need to be re-applied until fish updates it's snap?
I had the same problem on Linux Lite 6.0 (basically same as Ubuntu 22.04). Snap applications (Spotify, Prospect Mail) would not show up our could not even be found when searching for them. Just logging out and back in again put the application shortcuts in the Menu and all worked fine.
I have an application that deals with timezones, so naturally I want to be able to view the list of timezones in Postgresql.
I tried to view all available timezones with the following command:
SELECT * FROM pg_timezone_names;
Which prints the following error:
ERROR: timezone directory stack overflow
I even tried limiting the results and received the same error:
SELECT * FROM pg_timezone_names LIMIT 10;
At first I thought it might just be my IDE of choice having issues, but I tried to run the same sql query on the command line and received the same error. I can't, for the life of me, find an answer to this issue. Any information would be helpful. Thanks!
EDIT: I'm using Postgresql 9.3 on Gentoo. Self compiled version of postgresql-server.
Note: I can query the pg_timezone_abbrevs table just fine, just not pg_timezone_names.
According to this Postgres FAQ:
...
On platforms that receive regular software updates including new tzdata files, it may be more convenient to rely on the system's copy of the tzdata files. This is possible as a compile-time option. Most Linux distributions choose this approach for their pre-built versions of PostgreSQL.
...
The compile-time option referred to is the --with-system-tzdata, which is described about half-way down this page.
My guess is that this flag is set by the Portage distribution you're using, and that the tzdata is either missing or corrupted on your system. On Gentoo, the tzdata is distributed in the timezone-data package, which you can find here.
Try:
# emerge timezone-data
Then see if that fixes the problem.
This is an answer to my own question.
The following is at least true on the Gentoo distro of linux, but I assume can be present on others.
What causes the error mentioned in my post is a symlink loop by /usr/share/zoneinfo/posix
To solve this error you just have to delete that symlink, as follows:
rm /usr/share/zoneinfo/posix
Pretty easy fix. Be aware that any update to zoneinfo will cause this symlink to be recreated and thus requiring you to remove it again. I haven't had any issues with this link being removed, but I can't say the same for others. If anyone has a reason for NOT deleting this symlink, just post a comment stating so.
Had the exact same issue on Ubuntu 14.04 LTS with PostgreSQL 9.3.3 however my recursive symlink was with /usr/share/zoneinfo/localtime. Fixed by running:
$ sudo unlink /usr/share/zoneinfo/localtime
I can no longer use / at the windows xp command prompt, and it seems to have started after a botched cygwin installation, e.g. cd /windows won't work, but used to.
Can anyone think of how this might have happened?
OOPS! It doesn't normally work in XP, though I had read that it does in Vista. I simplified my problem and it was wrong. The real problem is:
I was using the cwrsync binaries (meant for cygwin use) that can be used at the command prompt in a way such as:
ssh -i /keydir/keyfile user#server
but after doing something (seems like it was installing cygwin), and even after reinstalling the cwrsync files, I can now only do:
ssh -i \keydir\keyfile user#server, i.e. I have to use the windows convention when referring to local files.
I posted this on the cwrsync forum, but it's not very active, so I was hoping someone might recognize what's going on here, I should maybe try the cygwin forum too.
Actually, since DOS 2.0, the kernel and file APIs have always supported forward slash, and many command line calls. See: http://blogs.msdn.com/larryosterman/archive/2005/06/24/432386.aspx.
I used to go to great pains to detect the OS and use a PATH_SEPARATOR type constant in PHP, when I discovered this by accident (it's use is now considered deprecated, in lieu of a simple "/").
Cheers.
You imagined it - it never worked.
If you happen to be in C:\ and type
C:\>cd /windows
it will take you to C:\WINDOWS\ but that's only because /windows is not a valid option to cd, so it tries ignoring the /.
Forward slash is a path separator in UNIX and cygwin, but Windows uses it for commandline options, eg. dir /w.