I am using Linux terminal
echo -n "ΒΓΔΕΖΗΘΙΚΛΜΝΞΠΡΣΤΥΦΧΨΩ" | iconv -f utf-8 -t ASCII//IGNORE//TRANSLIT
but error: ilegal sequence.
Expected result: something as Α=A, Γ=G, Δ=D, Ε=E, Λ=L, etc.
PS: similar to PHP's problem here but utf8 not accepted on terminal.
First of all, it should be echo -n "ΒΓΔΕΖΗΘΙΚΛΜΝΞΠΡΣΤΥΦΧΨΩ"|iconv -f UTF-8 -t ASCII//TRANSLIT. Note the capial UTF-8 and no IGNORE.
Second, there was a Greek transliteration table missing in glibc until recently. (iconv is part of glibc) [1]
If that bug still affects you there should be ????????????? given as output, but no error.
Anyway it is fixed for glibc 2.31 that is released on 2020-02-01 [2]
If you really need this before the new glibc makes into your distributive you could patch the glibc/locale/C-translit.h.in and recompile.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=12031
[2] https://sourceware.org/legacy-ml/libc-announce/2020/msg00001.html
NOTES
UBUNTU and many other Linux use glibc instead libc
on UBUNTU you can check version with the command ldd --version or dpkg -l libc6
Related
I'm installing harbor with source code.
✗ make install
the error is below:
...
Successfully built b917c04731a3
Successfully tagged goharbor/nginx-photon:dev
Done.
/bin/bash: --timeout: command not found
make[1]: *** [_build_registry] Error 127
make: *** [build] Error 2
I've tried to get coreutils and config my path
brew install coreutils
Edit :
The answer of #Arne Vogel is more likely to point the real problem.
Indeed it would be surprising that you don't have the command /bin/bash (so the steps I described here won't solve the issue).
coresutil is composed of GNU version of the most famous commands (cat, head, tail, wc, sort...), so it's not directly related to your problem.
You can use brew to install the latest version (version 5) of bash:
brew install bash
Double check if you really don't have a bash inside your /bin/:
sudo ls /bin/bash
It should returns a line like this (pay attention to the permission):
-r-xr-xr-x 1 root wheel 618416 Nov 30 12:55 /bin/bash
If it returns no result, then you may create a link:
sudo ln -s $(which bash) /bin/bash
TBH, I don't know about harbor, but this error seems to be caused by bad formatting in a script, specifically something like:
some-command --some-option --some-other-option \
--timeout
Now if the backslash (to continue the line) is missing, some-command will first be executed (without the --timeout option), and then bash will try to execute a command called --timeout, which, unsurprisingly, does not exist.
This problem can also be caused by an extraneous space after the backslash, a stray semicolon, wrong line terminators (in particular, Windows-style CRLF) etc.
Here are some suggestions for what you could do:
Make sure you have downloaded the source package appropriate for Mac OS X. Many open source packages are distributed in different formats, e.g. .zip and/or .7z for Windows, .tar.gz and/or .tar.bz2 for UNIX. You need either of the latter.
Check the documentation and/or forums, obviously.
If that doesn't help, use ktrace to find the offending script, and then look at it in a text editor. If you do find a bug in a script, consider reporting it to the developers.
In which file are stored the info about the command
bash --version
?
I've tried in some directories like /bin or /var, /etc, but without results...
I need both for Linux and MAC OS x. Thanks!
Do you have any reason to believe that it is not hard-coded in the bash-executable itself?
To find out which bash is used, run
which bash
For me, it gives /bin/bash. Now, to see whether the executable has any string-like byte sequences in it that contain the substring "version", run
strings /bin/bash | grep version
On this machine, it gives:
shell_version_string
build_version
sccs_version
rl_library_version
rl_do_lowercase_version
show_shell_version
rl_readline_version
dist_version
GNU bash, version %s-(%s)
GNU bash, version %s (%s)
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
#(#)Bash version 4.3.48(1) release GNU
display-shell-version
-l do not print tilde-prefixed versions of directories relative
HOSTTYPE The type of CPU this version of Bash is running under.
OSTYPE The version of Unix this version of Bash is running on.
version, type `enable -n test'.
do-lowercase-version
.gnu.version
.gnu.version_r
Thus, "Bash version 4.3.48" is hard-coded in the executable as an ordinary string.
strings $(which bash) | grep "Bash version"
Output (e.g.):
#(#)Bash version 4.3.48(1) release GNU
When executing grep on OSX my results are incorrect. I'm looking for the offset of a substring with several matches, using -aob. 'a' indicating that i'm using strings, 'o' only showing the result, and 'b' for the byte offset.
echo "ABDABCABC" | grep -aob "ABC"
With the output:
0:ABC
ABC
When in fact the output should be:
3:ABC
6:ABC
By default OSX uses BSD grep, which seems to have this problem. I'm using El Capitan, but other Mac users with earlier versions experience the same. I've tried installing GNU grep through homebrew. I can't seem to use it for grep though, grep -V return that it's using the BSD. MacPorts is having some issues right now, so I can't use that for installing.
I've also updated bash to the latest version, so I'm fairly certain that this isn't the source of my troubles.
On another note using Perl alternatives for grep isn't an option, this is for a homework assignment and one of the conditions is to not use Perl.
Does anyone have a solution for this? Either to fix the issue with BSD or a way to use an installed homebrew GNU grep.
Cheers.
BSD grep seems to give only byte offset to the beginning of the matched line, not to found pattern.
Regarding your question about GNU grep. I don't use Homebrew, but according to this grep formula it is installed by default with g prefix. Try: ggrep.
While Googling for another bash tip, I found this page on .inputrc http://ss64.com/bash/syntax-inputrc.html, which exactly fixed what I was trying to do (put a trailing / on symlinks to directories), but as I read further, I saw that there was a way to skip completed text as well. "Awesome", I said to myself, "this bugs me about twice a week". So, I put that into my .inputrc as well, but it doesn't work, or even seem to recognize what's going on. After logging out, and logging back in, this is what I'm seeing:
$ tail .inputrc
set mark-symlinked-directories on
set skip-completed-text on
$ bash --version
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0)
Copyright (C) 2007 Free Software Foundation, Inc.
$ bind -V | grep completed
$ bind -V | grep skip
$
That is, bash doesn't seem to recognize it's there at all... Is there something wrong with the version of bash supplied in Mountain Lion? Anything blindingly obvious I've forgotten to do?
skip-completed-text is new to bash version 4.
The: skip-completed-text is only in bash4.
On my Mac:
$ bash --version
GNU bash, version 4.2.37(2)-release (i386-apple-darwin12.1.0)
If you want install some opensource utilities i recommending you using macports (www.macports.org). Installing macports will give you one command called port and with it you can install things dead simply, like:
$ port install bash
will install bash 4 for you.
Bash v4 won't make it to OSX. Might I suggest zsh, which is not GPL3.
As the title suggests — can I be reasonably sure that mktemp will exist on any unix-y operating system I'm likely to encounter?
POSIX does not seem to specify mktemp(1).
It looks like most modern systems have it, but the available functionality and the semantics of the options vary between implementations (so particular invocations may not be portable):
mktemp(1) from OpenBSD — mktemp(1) originated in OpenBSD 2.1
mktemp(1) from FreeBSD
mktemp(1) from Mac OS X — almost always the same as from FreeBSD
mktemp(1) from Todd C. Miller of sudo fame
mktemp(1) from Solaris
mktemp(1) from GNU coreutils
mktemp(1) from HP/UX — this one seems particularly divergent from most of the others listed here
So if you want a portable solution you may need to stick to functionality and options that mean the same thing on all of your platforms of interest.
A mktemp function (AKA mktemp(3)) first appeared in Unix V7 so it's likely to be everywhere. However, a mktemp command (aka mktemp(1)) first appeared, I believe, on OpenBSD 2.1, so if you have to deal with truly antediluvian Unix systems you might have to worry -- unless you can distribute the very portable mktemp.org version (to fix the potential lack of this utility on some customer's antediluvian system). How likely you are to encounter antediluvian system is nigh impossible for us to guess, of course -- e.g., in HP-UX, mktemp(1) has been around for at least 8 years (even most enterprises probably have updated their Unix OS's within that time frame), in Xenix I believe it appeared in 3.0 (in 1992), etc, etc.
FYI, mktemp appears to NOT be included with Solaris 9 (released 2002/2003) - just ran across this today:
$ uname -a
SunOS dcmnapp02 5.9 Generic_122300-47 sun4u sparc SUNW,Sun-Fire-V440
$ mktemp
bash: mktemp: command not found
$ man mktemp
bash-2.05$ man mktemp
Reformatting page. Please Wait... done
Standard C Library Functions mktemp(3C)
NAME
mktemp - make a unique file name
SYNOPSIS
#include
char *mktemp(char *template);
On Solaris 9 it's in package SMCmktemp, see http://sunfreeware.com/indexsparc9.html:
uname -s
SunOS
uname -r
5.9
/usr/sbin/pkgchk -l -p /usr/local/bin/mktemp
Pathname: /usr/local/bin/mktemp
Type: regular file
Expected mode: 0555
Expected owner: bin
Expected group: bin
Expected file size (bytes): 8884
Expected sum(1) of contents: 6493
Expected last modification: Nov 05 08:48:17 2002
Referenced by the following packages:
SMCmktemp
Current status: installed