I've a problem using Linux Sort when i run on input like this:
07TLF\1\1\10040
07TLF\1\1\10060
07TLF03\10060
07TLF03\10080
07TLF\1\1\10320
07TLF\1\1\10360
07TLFS\10280
(\1 is Ctrl+A character). As you can see the 3rd and 4th row are wrong (should be the 5th and 6th).
If I use LC_COLLATE=C everything goes well! but in other similar cases sort works ok even if I use a different LC_COLLATE.
I use sort in a C program using system system call, but also running in bash I have the same behavier.
Can you help me?
thx
From the manpage of sort (1):
NAME
sort - sort lines of text files
I don't think, Ctrl+A is part of any file called "text file". If you have special requirements - as sorting special chars - you have to either use a utility serving the requirement or just implement it on your own if no such exists.
Since there is no "natural order" of special chars, you will hafe do define what you want the order to be. You may either set the locale to make sort behave according to the rules defined there or you have to implement your own sort algorithm, if none of the locales matches your requirements.
By the way: Using system is not a good idea at all if you can avoid it. You may never know which version of sort is installed on your target system and which rules are used.
Related
I am turning to use Sublime3 instead of Notepad++. I have some concern when working with Perl/PHP or any kind of languages that use dollar sign for declare variable.
Here is an example, in Notepad ++:
As can be seen, "HELO $name" was displayed with different colors.
By that way, we can easily recognize there is a variable in the string.
In Sublime 3 , it looked like this:
So you can see there are no different between text and variable. It would caused confusion in some case.
May I know is there are any solution for this ?
Thank you and best regards.
Alex
This is self-promoting, but it will actually solve the problem
You may want to check out my Neon Color Scheme, available via Package Control. Its goal is to make as many languages as possible look as good as possible, and has hundreds of selectors that are specific for many different syntaxes, including Perl and PHP. Specifically, both languages support highlighting for string interpolation. Here is your code using Sublime's Perl syntax from dev build 3118, which should be very similar to the latest public build, which you should be using if you're not registered yet:
And here is the equivalent code in PHP:
Please note that these images were taken using a work-in-progress version of Neon, which I'm planning on releasing in the next day or so. The current version should look the same, as I don't think I've edited any of these scopes, but if not just let me know and I'll point you to the dev version.
from https://stackoverflow.com/a/21666354/433570
It's dos based solution though, can it be done for linux based system?
I'm trying to highlight stuff in my log file.
For instance, I want to highlight the line of nginx log which has slower response time than 1 sec.
** edit **
Currently I'm using hi-lock-mode
eg, I put a mark on a line that shows slow response, then use regex & hi-lock to highlight it.
I guess this is ok solution, for now.
I am wondering if there's a better solution.
hi-lock mode with user-defined function rather than regex is what I would hope for.
I would define functions, and mapping between function-color.
Then I would M-x apply [function]
def slow(line):
if ... :
return True
return False
slow: yellow,
iPhone: blue,
I think this would be useful to inspect logs..
I wonder if there's a similar functionality available out there?
Why don't you write your own major mode for your files?
A basic major mode with font-lock support is not hard to implement. There are plenty of documentation on this on the net. All you need is a syntax table (so that Emacs would know which characters start strings etc.) and some font-lock rules for syntax highlighting.
The easiest, though, is to start with an existing one, for example ini-mode, a small major mode for editing Windows-style ini files.
Unless your files have a specific file extension or otherwise follow a specific naming convention, you might want to add an entry to magic-mode-alist, which provides you with a way to recognize specific files based on the content rather than the file name.
If you would like to see your files colored in a terminal window when viewed using more or less, you can use e2ansi, a package that use Emacs to generate an ANSI version of syntax highlighted files.
It goes like this:
exec("echo '" + param + "' > /etc/test")
And note that it's under root privilege and param has filtered characters like:
'
"
;
`
&
Your question will not get a yes/no answer without much more context. That's okay; instead let us look for weaknesses and highlight areas for concern.
Issue 1: it is almost always better to avoid passing untrusted/externally-supplied data into a shell command; the shell provides a dangerous level of power if someone manages to subvert your command with bad input. Open and write the file in your own code rather than using a shell to do it.
Issue 2: it's impossible to say if that exec() would be safe without knowing what shell the command line will be evaluated by.
Issue 3: if you must pass data via a shell (but see Issue 1), robust filtering is vital. But from your brief description of the filtering, it sounds like you are blacklisting known-bad characters - this is a poor approach, it is always better to whitelist known-good characters and keep that to a very limited set (such alphanumeric).
If you do not specify the PATH, then you cannot be sure what command is executed. You also did not say how you sanitize param. There are a few things to avoid:
Why do you use exec/echo at all? Any programming language can write to files directly.
the "single string" exec() method needs to deal with parsing/escaping. If you use a method which uses a string array, you dont need to be concerned with it.
In your case /etc is a safe dir, but if you use the same code on a less protected directory you might follow a symlink and destroy anything an attacker wants you to
You should be aware that the content of your newly created file contains blank delimited file names, but filesnames can contain blanks. So malicious attackers can produce new (non existing) names. (In fact all characters (including line breaks) besides \0 can be part of the filename).
You need to setup a clean (i.e. only add whitelisted entries) environment. LD_PRELOAD, PATH, IFS, CWD/PWD or SHELL, all can be tainted.
Is there a way to concatenate two OpenDocument Text documents (i.e. the format OpenOffice uses) in Linux from the command line? I'm looking for a command that will allow me to do something like:
concat-docs doc1.odt doc2.odt doc3.odt -o alldocs.odt
This hypothetical command would produce alldocs.odt, which would contain doc1, doc2, and doc3, one after the other.
I've already looked into doing this at the raw xml level, and it's rather complicated enough (renaming automatic styles to avoid conflicts etc.) that I'd prefer not to do it unless there aren't any other tools that will do what I want.
I am not able to double check right now, but you may want to check out some of the options available from the Python-UNO bridge or OOoPy. Both have utilities that sound like what you might want to do. Python-UNO bridge has something called oomerge.py that is described as "A command line tool, that creates a new document by appending multiple single documents", and OOoPy has a utility that is ooo_cat which is "for concatenating several OOo files into one".
Try these and post back with your findings....
I'm trying to localize a large MFC project where all the strings are hard-coded into the source code. (It was the easiest thing to do at the time, back before we had any idea we'd expand into other markets.) I've looked at localization tools, and invariably they say to put all the strings into the .rc file first, or just assume it has been done. Of the ones I've checked, appTranslator is the only one that even hints it may be a problem, and provides a couple of convenience functions to cut down on the wordiness of the resulting source code.
Does anybody have a better idea than going through hundreds of files manually, and making the occasional mistake along the way?
Is there some sort of product out there to help?
Does anybody have experience with doing this?
It is a tedious process to be sure. I participated in an effort like this many years ago. We did it manually. You can probably write some common code that makes the loading, checking, etc all pretty clean with minimal bloat.
I don't know of any products that will do it for you.
CStrings might be your friend - using the LoadString() member.
I would either derive from CString or write some other code that encapsulates default values (their current hard-coded values probably) and other error conditions and then use that in place of the hard-coded strings.
If you prefer not to use CString, then deriving from std::string and using the global LoadString() works fine too.
as for tools:
not sure they will work for your case:
http://www.modelmakertools.com/articles/hard-coded-strings.html
apparently this tool can find all the strings in your exe files:
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
Then you can search for them and replace.
I think writing a tool would be fairly straightforward - look for " character and then create an entry in an rc file that corresponds to the .cpp or .h file it came from. You will have a lot of culling to do, but it is a start. You can do a replace of the text, or insert comments, etc. You can use the line number and file name for the resource id/name in a #include.
I know it's too late but just for the search engine.
There is a feature of CString to initialize it from a resource ID.
CString((LPCTSTR)IDS_RESOURCE_ID)