I'm trying to install a locale on OSX (El Capitan) and I can't figure it out.
I've been googling for hours now.
In Ubuntu is as simple as locale-gen and dpkg-reconfigure.
I'm coding a PHP application that uses es_AR as a locale and I can't get my number formatting right.
Works fine in Linux systems.
Thanks.
First off, you already have asked this question here, and the Apple or Unix/Linux StackExchange pages are more appropriate for this question, however you put up bounty, and if nobody answers your question you don't get that bounty back, so I'll answer here and follow up with the same answer (if you find it formidable) on that other page.
Unfortunately Apple really did not create a locale for Argentina, so when you look at the Language & Region section in the OSX settings, the difference between Español (Spain) and Español (Latinoamérica) is really non-existent in OSX. When I enabled either, there was no change on the available locales on my system:
$ locale -a | grep es
es_ES
es_ES.ISO8859-1
es_ES.ISO8859-15
es_ES.UTF-8
So unfortunately Apple did not include the es_419 (Latin America) or es_AR (Argentina) locales, and they tied those up into the es_ES locale.
In talking to a friend who travels to Argentina frequently, is fluent in Spanish and also uses Spanish on their Mac:
There could be slight spelling differences but mostly it's the grammar. It would just be some Spain Spanish grammar, but Argentines use some variants of Spain conjugations.
So really it should not matter in the long run. You can simply copy the locale on Mac to match the naming:
sudo cp -R /usr/share/locale/es_ES /usr/share/locale/es_AR
Also I checked on a few of my Linux hosts, and the sha256 sum for these locales are the same, so it looks like the Linux developers have done the same exact thing that Apple has basically done.
$ sha256sum /usr/share/locale/es_ES/LC_MESSAGES/libvisual-0.4.mo
20848a8a8d6ddca454825b3b4102393699850d156d7157535850556e110fb891
$ sha256sum /usr/share/locale/es_AR/LC_MESSAGES/libvisual-0.4.mo
20848a8a8d6ddca454825b3b4102393699850d156d7157535850556e110fb891
Related
For some reason, wget has started printing all of its messages in Russian, but only when run from within PyCharm's terminal. Why is this happening and how can I change it back to English?
I am on OSX 10.13, and am using wget 1.19.4_1 installed using Homebrew. I have used wget on this computer before, and the text was in English. I cannot understand Russian, so nothing on this computer has ever been set to use Russian.
When I run ...$ locale, this is the result:
LANG=
LC_COLLATE="C"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=
Here's what I've found so far
This only happens for terminals in JetBrains IDEs -- I have tried both PyCharm and JGrasp, and they are both affected. When run in the OSX Terminal app, wget outputs English text. It would still be nice to know why this is happening and how to fix it.
This problem seems to affect only wget
Reinstalling wget using brew does not seem to have any effect.
There is no en_US locale in /usr/local/Cellar/wget/1.19.4_1/share/locale/, but I do not know if this could be the cause of my problem.
Copying .../en_GB/ (where ... is wget's locale folder) into a new folder called .../en_US/ does not get rid of the Russian text. Nor does replacing .../ru/ with .../en_GB/. I'm not sure exactly how a locale is defined, so this may or may not mean anything.
This just happened to me, except in french.
My fix: force in the lang values in the terminal
export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8
This has wget happy; I've added them to ~/.profile now to see if it keeps them away forever.
jGRASP is using a pty to connect to external programs, and some other IDEs are probably doing the same. So it's possible that new ptys created the way these IDEs are doing it are defaulting to the wrong locale.
From jGRASP or another IDE you can compile and run a Java or C program to print the default locale to verify this. For Java it is java.util.Locale.getDefault() .
The source for the jGRASP pty connection is in .../jGRASP.app/Contents/Resources/jgrasp/src/wedge.c . You can see how the pty is created there. You can also modify and recompile to .../jgrasp/jbin/osx_run if it will help to trace down the problem. Compiling on OS X requires no special parameters, just: cc -o ../jbin/osx_run wedge.c .
This might seem like a silly question but I haven't been able to find a clear answer.
This website states that the dash is optional in
ps aux
However, ps aux works but ps -aux brings up the error no user named 'x'. Any ideas what the issue may be here? Running Mac 10.8.2. Thanks
man ps
will give you this:
The biggest change is in the interpretation of the -u option, which now
displays processes belonging to the specified username(s). Thus, "ps
-aux" will fail (unless you want to know about user "x"). As a conve-
nience, however, "ps aux" still works as it did in Tiger.
Back in the day (from the late 1970s), there were basically two varieties of UNIX, the AT&T version from Bell Labs and the BSD version from UC Berkeley. The options to ps were different in the two versions. OS X now mostly conforms to the modern UNIX standard which follows the AT&T options to ps. But since the BSD ps didn't require a leading '-' option and so many people were used to typing 'ps aux', Apple has decided to leave that sequence with its original BSD interpretation.
I'd like to mount a Samba drive in OS X using bash. This line does the trick:
mount -t smbfs //$SAMBAUSER#$ADRESS/$NAMEOFSHARE $MACOSXPATH
only one problem. I want it done without user input - which means no password can be manually put in. And I'm not going to ask my users to download fink just so they can install expect (as seen here).
I tried applying the accepted solution to a similar StackOverflow problem shown here by doing this:
echo "mypassword" | mount -t smbfs //$SAMBAUSER#$ADRESS/$NAMEOFSHARE $MACOSXPATH --stdin
but no luck - that doesn't work and Mac OS X tells me I used mount command improperly:
usage: mount [-dfruvw] [-o options] [-t ufs | external_type] special node
mount [-adfruvw] [-t ufs | external_type]
mount [-dfruvw] special | node
Any suggestions? This would be easy with an expect script - but that would ruin the user experience to have that prerequisite in my mind.
If mount(8) can't just call the mount syscall on the filesystem, it looks for a program to help it. On FreeBSD and Mac OS X, those helper programs follow the naming convention mount_XXX, where XXX is the -t argument's value.
That means you want to check the mount_smbfs(8) man page, which tells us about -N:
-N Do not ask for a password. At run time, mount_smbfs reads the ~/Library/Preferences/nsmb.conf
file for additional configuration parameters and a password. If no password is found,
mount_smbfs prompts for it.
Unfortunately the man page trail ends with one for nsmb.conf that doesn't mention anything about storing passwords. On FreeBSD 8.0, at least, the solution is to put a password key with a plain text(!) password value under a [SERVER:USER] heading. That would be type C according to the linked nsmb.conf man page.
So it seems that you'll want to dump a pre-configured nsmb.conf into your user's ~/Library/Preferences/ directory and then call your mount command with -N. As far as I know you can't provide a hashed value, which is not especially awesome. I'll try to get access to a MacBook in a few hours to test this.
NB: This is not how to do it with the GNU toolchain. If you're on Linux, you're probably going to be using something like mount.cifs(8). The correct solution in that case is the credentials=filename option (used after -o, of course), where filename is a file of credentials in key=value form, separated by newlines. See http://linux.die.net/man/8/mount.cifs
The answer in this apple support discussion thread worked for me:
osascript -e 'mount volume "smb://user:password#server/share"'
I'll give you 2 options. First, include the password on the command line:
mount -t smbfs //$SAMBAUSER:$PASSWORD#$ADRESS/$NAMEOFSHARE $MACOSXPATH
This is not a great option because the command line (including password) is visible to anyone who happens to be logged in at the moment. Not great, but it is a possibility.
Second, use expect. The Mac OS X Hints article you linked dates from 2002, when OS X v10.2 would've been current. While 10.2 apparently didn't include expect as a standard component, 10.6 does, and I'm pretty sure it's been included for several versions now.
#!/usr/bin/expect -f
spawn mount -t smbfs //fred#12.34.56.78/myfiles /tmp/mountpoint
expect "Password:"
send "wibble\r"
wait
You not only can use a hashed value, you're expected to, at least in older releases. The crypt option for smbutil is not DOD-level security but as with most security, you're trying to keep the honest people honest: the bent ones will find a way. It seems to be broken in Mountain Lion but the nsmb.conf file in ~/Library/Preferences should be secure at the OS level. The /etc/nsmb.conf would override it if it exists. I'm sure there's a reason why plain text files are obsolete but didn't we go this with NetInfo? How long did it take for Apple to allow the old standbys (/etc/hosts, /etc/passwd) to be used?
Okay, so I finally got myself a MacBook Air after 15 years of linux. And before I got it my big concern was UTF-8 support because no matter if I get files sent to me from windows or mac-clients theres always issues with encoding, while on ubuntu I can be sure that all output no matter what program will produce perfect utf-8 encoded data.
And now on my second day (today) with OS X Im tearing my hair of by frustration. Why?
When I open Nano and type some swedish characters like ÅÄÖ in it, it puts out blank characters at the end of the line (which i guess is the other byte in each character)
When I open python and try using swedish characters, it does not output anything at all
When I connect to a Ubuntu server trough SSH I cant type åäö in bash, tough it works in VIM (still trough SSH). And in nano backspace does not work, but if check the box "Delete sends ctrl+H" in the Terminal preferences, backspace starts working in nano but stops working in VIM.
I've tried unchecking all other encodings then UTF-8 in terminal preferences but that does not seem to work either.
I'm sure that every non US-person must have the same issues, so hove do I fix them? I just want full UTF-8 support... :'(
For me, this helped:
I checked locale on my local shell in terminal
$ locale
LANG="cs_CZ.UTF-8"
LC_COLLATE="cs_CZ.UTF-8"
Then connected to any remote host I am using via ssh and edited file /etc/profile as root - at the end I added line:
export LANG=cs_CZ.UTF-8
After next connection it works fine in bash, ls and nano.
Go to Terminal -> Preferences -> Advanced (Tab) go down to International and select Unicode (UTF-8) as Character Encoding.
And tick Set locale environment variables on startup.
Unfortunately, the Preferences dialog is not always very helpful, but by tweaking around you should be able to get everything working.
To be able to type Swedish characters in Terminal, add the following lines to your ~/.inputrc (most likely you must create this file):
set input-meta on
set output-meta on
set convert-meta off
This should do the work both with utf8 and other codings in bash, nano and many other programs. Some programs, like tmux, also depends on the locale. Then, adding for instance export LC_ALL=en_US.UTF-8 to your ~/.profile file should help, but keep in mind that a few (mainly obscure) programs require a standard locale, so if you have trouble running or compiling a program, try going back to LC_ALL=C.
Some references that may be helpful:
http://homepage.mac.com/thgewecke/mlingos9.html#unicode
http://hints.macworld.com/article.php?story=20060825071728278
The following is a summary of what you need to do under OS X Mavericks (10.9). This is all summarized in
http://hints.macworld.com/article.php?story=20060825071728278
Go to Terminal->Preferences->Settings->Advanced.
Under International, make sure the character encoding is set to Unicode (UTF-8).
Also, and this is key: under Emulation, make sure that Escape non-ASCII input with Control-V is unchecked (i.e. is not set).
These two settings fix things for Terminal.
Make sure your locale is set to something that ends in .UTF-8. Type locale and look at the LC_CTYPE line. If it doesn't say something like en_US.UTF-8 (the stuff before the dot might change if you are using a non-US-English locale), then in your Bash .profile or .bashrc in your home directory, add a line like this:
export LC_CTYPE=en_US.UTF-8
This will fix things for command-line programs in general.
Add the following lines to .inputrc in your home directory (create it if necessary):
set meta-flag on
set input-meta on
set output-meta on
set convert-meta off
This makes Bash be eight-bit clean, so it will pass UTF-8 characters in and out without messing with them.
Keep in mind you will have to restart Bash (e.g. close and reopen the Terminal window) to get it to pay attention to all the settings you make in 2 and 3 above.
Short versatile answer (fits to other national languages, even Lithuanian or Russian)
open Terminal
edit .profile in home directory - nano .profile or in Catalina or newer nano .zshenv
add line export LC_ALL=en_US.UTF-8
press Ctrl+x and Y (exit and save)
This solved for me even small country rare national characters. You may need to close and open Terminal to make changes effective.
Also if you like Linux behavior (use lot of Alt shortcuts like Alt+. or Alt+, in mc) then you should disable Mac style Option key function:
Terminal->Preferences->Profiles->Keyboard and check box:
Use Option as Meta key
To make nano work as you want it to, try:
export LANG="UTF-8"
Or get a newer version of nano via MacPorts:
# cf. http://www.macports.org/install.php
port info nano
port variants nano
sudo port install nano +utf8 +color +no_wrap
With respect to ssh & UTF-8 issues comment out SendEnv LANG LC_* in /etc/ssh_config.
See: Terminal in OS X Lion: can't write åäö on remote machine
My terminal was just acting silly, not printing out åäö. I found (and set) this setting:
Under Terminal -> Preferences... -> Profiles -> Advanced.
Seems to have fixed my problem.
Check whether nano was actually built with UTF-8 support, using nano --version. Here it is on Cygwin:
nano --version
GNU nano version 2.2.5 (compiled 21:04:20, Nov 3 2010)
(C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007,
2008, 2009 Free Software Foundation, Inc.
Email: nano#nano-editor.org Web: http://www.nano-editor.org/
Compiled options: --enable-color --enable-extra --enable-multibuffer
--enable-nanorc --enable-utf8
Note the last bit.
Since nano is a terminal application. I guess it's more a terminal problem than a nano problem.
I met similar problems at OS X (I cannot input and view the Chinese characters at terminal).
I tried tweaking the system setting through OS X UI whose real effect is change the environment variable LANG.
So finally I just add some stuff into the ~/.bashrc to fix the problem.
# I'm Chinese and I prefer English manual
export LC_COLLATE="zh_CN.UTF-8"
export LC_CTYPE="zh_CN.UTF-8"
export LC_MESSAGES="en_US.UTF-8"
export LC_MONETARY="zh_CN.UTF-8"
export LC_NUMERIC="zh_CN.UTF-8"
export LC_TIME="zh_CN.UTF-8"
BTW, don't set LC_ALL which will override all the other LC_* settings.
Try
Having a Powerline compatible font installed https://github.com/powerline/fonts
Setting these ENV vars in .zshrc or .bashrc:
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
Just add a file on remote server
$ sudo nano /etc/environment
LANG=en_US.utf-8
LC_ALL=en_US.utf-8
PS: Top answer has a suggestion to change /etc/profile file on remote server, it works, but this file is often overwritten by system, and doesn't help for long.
/etc/profile file contains disclaimer:
It's NOT a good idea to change this file unless you know what you are doing. It's much better to create a custom.sh shell script in /etc/profile.d/ to make custom changes to your environment, as this will prevent the need for merging in future updates.
In my case, simply using the uxterm command instead of xterm solved the problem. It's available in /opt/X11/bin/uxterm by installing the XQuartz package provided by Apple.
I’m writing a LaTeX package which needs to use \write18. Some of the shell commands I issue are system-specific (e.g. rm vs. del). Is there a way to determine what system I’m running on?
It would be enough to disambiguate between Windows and other (Unix-like) systems.
Take a look at the LaTeX ifplatform package. There was a lot of discussion about reliable methods across a range of platforms, and the current release works very well.
Not very good but it works for me
\newread\checkf
\immediate\openin\checkf = C:/WINDOWS/win.ini
\ifeof\checkf not windows \else windows\fi
\closein\checkf
If you can mark your OS with a file you can do
\IfFileExists{/etc/motd}{unix code here}{windows code here}
There's nothing special about the path /etc/motd; it's just likely to be found on a Unix system and unlikely on a Windows system. If you want to be dead certain, you should create a file specifically to mark the system in whatever way you want to identify it.
A friend of mine had the following idea which I’m now using. I’ve only tested it on Windows XP and OS X where it works fine. A bit flimsy on testing, admittedly, but in principle it should work fine almost anywhere else.
\newif\ifwindows
\immediate\write18{echo $SHELL > \jobname.os}
\newread\#whichos
\immediate\openin\#whichos\jobname.os
\read\#whichos to \#whichosshell
\ifthenelse{\equal{\#whichosshell}{$SHELL }}
{\windowstrue}
{\windowsfalse}
\closein\#whichos
\ifwindows
\typeout{System detected: Windows}
\newcommand\DeleteFile[1]{\immediate\write18{del #1}}
\else
\typeout{System detected: Unix-like}
\newcommand\DeleteFile[1]{\immediate\write18{rm #1}}
\fi
% Cleanup.
\DeleteFile{\jobname.os}
The key here is that Windows won’t expand the $SHELL environment variable (any other variable would have done, really) so it will write the string $SHELL to the file literally.