i run this command :echom system("date")<CR> in vim.
my expected output is something like this: Sat Jan 10 12:28:58 CET 2015
but it always appends an annoying ^#
so that the output is like this: Sat Jan 10 12:28:58 CET 2015^#
why?
and how can i easily avoid this?
when i run date in terminal it gives me the expected output. plus a newline of course (*1). so my guess is, that the ^# comes from the newline, right?
i run vim 7.3 on debian (the version from the official repositories) in the terminal version, (not the gui version!) in a gnome-terminal with utf-8 encoding.
(*1): the prompt looks like this
user#host$ date
Sam Jän 10 12:28:58 CET 2015
user#host$
not like this:
user#host$ date
Sam Jän 10 12:28:58 CET 2015user#host$
The ^# does come from the fact that date ends with a newline (\n).
You can either :
remove the trailing characters (this will only output the expected result if the command ends with a newline) :
:echom system("date")[:-2]
substitute the trailing \n (a bit more verbose) :
:echom substitute(system("date"), '\n$', '', '')
Related
How to convert any date to YYYYMMDDHHMMSS using unix shell script?
It is not specific date it may any date. how to convert it?
example date format is: 20110101050603
Thanks
Puspa
DATE = "15 Jun 2015 10:10:10"; date -d"$DATE" +%Y%m%d%H%M%S
Output :-
20150615101010
More on Dates
Note this only works on GNU date.
I have read that:
Solaris version of date, which is unable to support -d can be resolve with replacing sunfreeware.com version of date.
Update:-
Use ls command to find all files and use grep command for all files.
ls | grep "[0-9]{14}"
grep command also accepts regular expression.
But it won't validate your file accurate. For example, if a file name is 20151835101010, then it will validate this file. But actually month and date both are wrong.
So my suggestion is to write a shell script to identify valid file name and find oldest of them by processing one by one.
I used ksh a lot but now moving to csh as this company has all scripts etc written in that.
One thing I loved about ksh was the ease of using the command history.
In case I have to edit the last command or second last command, I could easily press "Escape - k" to cycle through the commands and easily edit them.
csh does not seem to have a good equivalent. It displays all the history of commands then I have to copy paste one of them and then edit.
That's a pain when you want just change the number of in the file name for example :
cat abcdef1 | grep "Linking"
You could use (as a workaround):
"The most commonly used feature of csh command history is "!!" (pronounced "bang bang") which recalls the previous command":
% date
Mon Nov 25 13:52:36 PST 1996
% !!
date
Mon Nov 25 13:52:52 PST 1996
Here some other useful commands.
But you could just work in ksh and make script and whatever in csh.
If it is istalled simply launch:
/bin/ksh
My command line isn't behaving as expected. When I write something that is longer than the window width, the cursor goes back to the beginning of the same line and continues to write on top of the same line instead of automatically moving to the next line. For example, if I write "this is a line to illu" on the command line of my terminal the following is what I see:
Last login: Thu Jun 19 18:32:24 on
e to illu > ~] $ this is a lin
Note how the end of the text was being shown at the beginning of the same line. If the terminal window is wide enough I see this:
Last login: Thu Jun 19 18:32:24 on
[MacBook > ~] $ this is a line to illu
I'd like it to behave like this:
Last login: Thu Jun 19 18:32:24 on
[MacBook > ~] $ this is a line to illustrate
the problem
How can I solve this?
Thanks.
Unusual but I found the solution. #Barmar, you're right. I customised the colours of my terminal by configuring my PS1. It turned out that I was missing a backslash inside my PS1 quote preceding the color set. My PS1 was:
PS1="\e[0;30m[\h > \W] \$ \e[m "
resulting in the command lines not wrapping to the next line. I changed to:
PS1="\\[\e[0;30m[\h > \W] \$ \e[m "
Problem solved!
I have emails coming into a processing system, and some of them have started coming in with an invalid blank line splitting the email headers, like this:
Date: Thu, 7 Mar 2013 22:24:44 +0000
Message-ID: <86A1035194F72547A2979A7767CD3BAF35485B8D#QTS-MB02.ecicloud.com>
References: <C0DA0966847B31409025BBD9A70187DA35399D17#QTS-MB02.ecicloud.com>
Accept-Language: en-US
Content-Language: en-US
The blank line in the middle is invalid and causes problems for downstream programs.
I'd like to come up with a simple sed script to fix any occurences specifically of Accept-Language:.* preceded by a blank line, so that the blank line is eliminated.
Delete all blank lines in a lines in file with sed:
sed -i '/^\s*$/d' file
Delete blank line from the start of the file upto the line starting Content-Language:
sed -i '1,/^Content-Language/{/^\s*$/d}' file
sed '/^[ \t]*$/ {N;/\nAccept-Language: en-US$/! P;D;}' FILE
You should really look at the formail and procmail commands for processing email. See http://www.procmail.org/ and http://linuxcommand.org/man_pages/formail1.html.
I'm playing with bash, experiencing with utf-8 encoding. I'm new to unicode.
The following command (well, their output) surprises me :
$ locale
LANG="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_CTYPE="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_ALL=
$ printf '1\né\n12\n123\n' | egrep '^(.|...)$'
1
é
12
$ touch 1 é 12 123
$ ls | egrep '^(.|...)$'
1
123
Ok. The two egrep filters lines with one or three characters. Their input is quite similar, but the output differs with the character é. Any explanation?
More details on my environment :
$ uname -a
Darwin macbook-pro-de-admin-6.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386
$ egrep -V
egrep (GNU grep) 2.5.1
Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Any variable length encoding can mess with tools that is not aware of the encoding, and considers bytes, not characters, when you use single-character wildcards (because the tool assumes that byte=character). If you use literal characters, then for UTF-8, it doesn't matter since the structure of UTF-8 prevents matches in the middle of a character (assuming proper encoding).
At least some versions of grep are supposed to be UTF-8 aware, according to http://mailman.uib.no/public/corpora/2006-December/003760.html, GNU grep 2.5.1 and later is included there as long as an appropriate LANG is set. If you use an older version, however, or something other than GNU grep, that would likely be the cause of your problem, since é is a two-byte character (0xC3 0xA9).
EDIT: Based on your recent comment, your grep is probably Unicode-aware, but it does not perform any sort of Unicode normalization (and I wouldn't really expect it to, to be honest).
0x65 0xCC 0x81 is an e, followed by COMBINING ACUTE ACCENT (U+0301). This is effectively two characters, but it's rendered as one due to the semantics of combining characters. This then causes grep to detect it as two characters; one for the e and one for the accent.
It seems likely that decomposed Unicode is how the file name is actually stored in your file system - otherwise, you could store files that, for all intent and purposes, have the exact same name, but only differ in their use of combining characters.