I have a problem inside my .sh file.
When executing the following commands:
ftp -v server.name.net
Connected to server.name.net
220 Microsoft FTP Service
ftp> ls
the result is
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
2014_01_00500_Indennit▒ malattia.xlsx
and not 2014_01_00500_Indennità malattia.xlsx
The same happens for the following characters: è, ì, ò, ù
The server is faulty , or possibly it's not actualy an FTP server at all
according to RFC959 non-ASCII characters are illegal in filenames
<pathname> ::= <string>
<string> ::= <char> | <char><string>
<char> ::= any of the 128 ASCII characters except <CR> and <LF>
Related
I'm trying to integrate Rust Analyzer with a browser based editor.
My first step is to run Rust Analyzer directly from a terminal and send requests via stdio.
$ rust-analyzer
> Content-Length:207\r\n\r\n{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":null,"rootPath":"/mnt/78b33d24-344b-43da-a40c-8b81a6fd0b34/projects/rustexplorer/quick_test","initializationOptions":{},"capabilities":{}}}
But I got this error:
[ERROR rust_analyzer] Unexpected error: expected initialize request, got Err(RecvError)
expected initialize request, got Err(RecvError)
What am I missing here?
It's just because the four literal characters \ r \ n are not transformed into the two special characters \r and \n when you input them directly in the terminal.
In order to experiment by hand in the terminal, you should transform the line ending.
$ sed -u -re 's/^(.*)$/\1\r/' | rust-analyzer
Content-Length: 207
{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":null,"rootPath":"/mnt/78b33d24-344b-43da-a40c-8b81a6fd0b34/projects/rustexplorer/quick_test","initializationOptions":{},"capabilities":{}}}
... then the response is displayed here ...
Note that we press the Enter key here; we do not try to input the \n special character.
And on a second thought, I think that in this case (interactive terminal) you should provide Content-Length: 209 because the json content will be ended with \r\n (two more bytes, ignored as separators).
This way, the next request can be input on the next line.
If you keep 207, then your next request should start on the same line as the json content (right after the last }).
Another solution would be to change the settings of the terminal.
stty -icrnl makes the Enter key produce the \r (control-M) character; you then have to input control-J to produce the \n character.
$ stty -icrnl
$ rust-analyser
Content-Length: 208^M <-- Enter + control-J
^M <-- Enter + control-J
{"jsonrpc":"2.0", ... ,"capabilities":{}}} <-- control-J
... the response is displayed here ...
I am trying to login to remote DB2 using clpplus but can't login as password contains #.
clpplus -nw user/p#sswd#145.xx.xx.212:60000/Dbname
but it fails saying:
[jcc][t4][10380][11951][4.27.25] Required property "sswd#145.xx.xx.212" is
unknown host. ERRORCODE=-4222, SQLSTATE=08001
Is there any work around of it?
With the bash shell, enclose the password with \' and additionally escape the # with \# (and the same for any special character inside the password, i.e. escape it with \ ).
This example works for me:
clpplus -nw user/\'p\#zzword\'#myhostname:50002/sample
This question already has an answer here:
Why would a correct shell script give a wrapped/truncated/corrupted error message? [duplicate]
(1 answer)
Closed 5 years ago.
I am having errors where I am putting in code that should be working fine into a shell file and when I run it, it fails to run correctly. The error I am receiving from this is confusing me as well somewhat. Here is what I have:
echo "Please enter your student ID: "
read username
echo "Please enter your MySQL password: "
read -s password
db="db$username"
echo "DB username is $db"
$(mysql -D$db -u$username -p$password -se "CREATE TABLE...")
echo "That has been completed"
The SQL command has been truncated as this appears to have no relevance for the error.
If I run this code through putty I get this:
*******#csl-*******:~/tasks/SQL$ ./generate.sh
Please enter your student ID:
': not a valid identifierad: `username
Please enter your MySQL password:
': not a valid identifierad: `password
DB username is db
ERROR 1045 (28000): Access denied for user '-p'#'localhost' (using password: NO)
./generate.sh: line 7: $'\r': command not found
That has been completed
*******#csl-*******:~/tasks/SQL$
(The * represent hidden values)
I am not sure what the error is with this code here. I have tried under different circumstances such as using a Mac to create the file with exactly the same file on and run it through terminal and it works fine (off the same Linux server). However I also went back to the same Mac to try and re-run the code and got the same error as shown here - even though the code hasn't changed.
Some background information:
Using Putty for SSH access, Filezilla for FTP, Sublime Text for code editor. Connecting to a remote Linux server to run from.
I think this is due to having the wrong line ending character, which would be the case if you are running sublime in windows.
Try running od -xcb to find the carriage return characters. Unix expects just \n whereas you will see \r\n with windows carriage returns.
You can fix your file by running dos2unix generate.sh.
As per Dannys comment below you can change the settings in sublime by going to view > line endings > unix.
Examples:
I copied your script and created a file using vim with unix carriage returns called script.sh. I then used unix2dos to create a file with windows carriage returns for testing and was able to recreate your error.
Unix carriage returns:
od -xcb script.sh
0000000 2123 622f 6e69 622f 7361 0a68 6365 6f68
# ! / b i n / b a s h \n e c h o
Windows carriage returns:
od -xcb windows.sh
0000000 2123 622f 6e69 622f 7361 0d68 650a 6863
# ! / b i n / b a s h \r \n e c h
And the error from the windows script:
> . windows.sh
Please enter your student ID:
': not a valid identifier
Please enter your MySQL password:
': not a valid identifier
DB username is db12
That has been completed
My file names look the same but they are not.
I copied many_img/ from Debian1 to OS X, then from OS X to Debian2 (for maintenance purpose) with using rsync -a -e ssh on each step to preserve everything.
If i do ls many_img/img1/* i get visually the same output on Debian1 and Debian2 :
prévisionnel.jpg
But somehow, ls many_img/img1/* | od -c gives different results:
On Debian1:
0000000 p r 303 251 v i s i o n n e l . j p
0000020 g \n
On Debian2:
0000000 p r e 314 201 v i s i o n n e l . j
0000020 p g \n
Thus my web app on Debian2 cannot match the picture in the file system with filename in database.
i thought maybe i need to change file encoding, but it looks like it's already utf-8 on every OS:
convmv --notest -f iso-8859-15 -t utf8 many_img/img1/*
Returns:
Skipping, already UTF-8
Is there a command to get back all my 40 thousands file names like on my Debian 1 from my Debian 2 (without transfering all again) ?
I am confused if it is a file name encoding problem or anything else ?
I finaly found command line conversion tools i was looking for (thanks #Mark for setting me on the right track !)
Ok, i didn't know OS X was encoding file names under the hood with a different UTF-8 Normalization.
It appears OS X is using Unicode Normalization Form D (NFD)
while Linux OS are using Unicode Normalization Form C (NFC)
HSF+ file system encode every single file name character in UTF-16.
Unicode characters are Decomposed on OS X versus Precomposed on Linux OS.
é for instance (Latin small letter e with acute accent), is technically a (U+00E9) character on Linux
and is decomposed into a base letter "e" (U+0065) and an acute accent (U+0301) in its decomposed form (NFD) on OS X.
Now about conversion tools:
This command executed from Linux OS will convert file name from NFD
to NFC:
convmv --notest --nfc -f utf8 -t utf8 /path/to/my/file
This command executed from OS X will rsync over ssh with NFD to NDC
on the fly conversion:
rsync -a --iconv=utf-8-mac,utf-8 -e ssh path/to/my/local/directory/* user#destinationip:/remote/path/
I tested the two methods and it works like a charm.
Note:
--iconv option is only available with rsync V3 whereas OS X provides an old 2.6.9 version by default so you'll need to update it first.
Typically to check and upgrade :
rsync --version
brew install rsync
echo 'export PATH=/usr/local/bin:$PATH' >> ~/.profile
The first filename contains the single character é while the second contains a simple e followed by the combining character ́ (COMBINING ACUTE ACCENT). They're both valid Unicode, they're just normalized differently. It appears the OS normalized the filename as it created the file.
In my vim, I can use :%!sed "s/^/ /", got the wrong output when I use :%!sed 's/^/ /' .
sed: -e expression #1, char 0: no previous regular expression
Is there differences between single quote and double quote in vim command mode?
In my sed, single quote is the same as double quote.
$ echo "wha012" | sed 's/w/haha/'
hahaha012
$ echo "wha012" | sed "s/w/haha/"
hahaha012
my system is xp+vim 7.3 for windows.
In my system:
[1] "c://cygwin/bin/ash.exe"
[2] "c://cygwin/bin/bash.exe"
[3] "c://cygwin/bin/dash.exe"
[4] "c://cygwin/bin/sh.exe"
if i set set shell=\"c:\cygwin\bin\sh.exe"\ -f in _vimrc,i get the new wrong messages:
sed command can not found.
Funny, when I try :%!sed "/^/ /" I get the same error message as when I use single quotes:
sed: 1: "/^/ /": invalid command code /
(This line replaces the content of my file.) I expect to get an error message there because, as #Birei pointed out, you left out the sed s command. This works as expected, with either single or double quotes:
:%!sed "s/^/ /"
#Birei is also right that you can use vim to do things like this, but I assume you have simplified the example from what you were really trying to do.
To answer the original question, Vim uses single quotes for literal strings. The only special character in a literal string is ' itself. Strings delimited with double quotes use \ to denote special character, such as `"\<Esc>".
:echo 'a''b' == "a'b"
:help expr-string
:help literal-string
my system is xp+vim 7.3 for windows
By default Vim uses cmd.exe to run :! commands on Windows, which behaves differently with regard to quoting from the POSIX shell that your s/w/haha/ examples suggest you've been testing with. Try something like
:set shell=\"C:\path\to\sh.exe\"\ -f
to tell it to use your POSIX shell instead. Or if you're using cygwin then try the cygwin version of vim instead of the Windows native one.
The difference is in the sed command, that lets interpolate variables when you execute it directly from the shell, like:
sed "s/$pattern/$replacement/"
but your problem is that you have to use a substitution command that begins with letter s, like:
:%!sed "s/^/ /"
Also you can have same behaviour inside vim without an external command, like:
:%s/^/ /