I am using a glossary search program called Xbench, and it allows you to use command line parameters to automatically jump to the relevant line in the file where your search term is. The developer told me to look for tips on how to achieve this with EmEditor # https://docs.xbench.net/user-guide/xbench-settings/
There, it is explained how to achieve this with Textpad and Notepad++.
See:
For example, to configure TextPad 4 for line positioning, you must
select there the Textpad executable and specify the following in
Command-Line Parameters: $filename($line,$column). Similarly, to
configure Notepad++, you must select its executable and specify the
following in Command-Line Parameters: $filename -n$line. Other text
editors will require different values for this field. Please check
your text editor’s documentation for the suitable values.
I had a look at EmEditors command line options # http://www.emeditor.org/en/howto_file_file_commandline.html, but can't figure out how to do this. Can someone help me?
Michael Beijer (technical/patent translator)
Please try this:
$filename /l $line /cl $column
If a file name contains a space, you might need to use this:
"$filename" /l $line /cl $column
Related
I am creating an IDE and I wish to implement jump to definition.
I found the perfect tool for it: ctags (https://github.com/universal-ctags/ctags)
Now the only problem is that the tags file that ctags create looks something like this:
QLineNumberArea 2point56mb.py /^class QLineNumberArea(QWidget):$/;" c
I understand the format: {tagname}Tab{tagfile}Tab{tagaddress}
So from what I understand: tagname: QLineNumberArea, tagfile: 2point56mb.py and tagaddress: /^class QLineNumberArea(QWidget):$/;" c`
The tagaddress looks like gibberish but it's a vim/ex editor command that takes you to the definition.
Now from what I read on this website: https://github.com/cztchoice/ctags/wiki/Tag-Format
Under Security it states:
Specifically, these two Ex commands are allowed:
A decimal line number:
89
A search command. It is a regular expression pattern, as used by Vi, enclosed in // or ??:
/^int c;$/
?main()?
Now here comes the problem:
I need my tags file to have a line number, instead of the search command.
I tried looking the documentation for ctags (http://docs.ctags.io/en/latest/) but I couldn't find anything that would help me.
Does anyone know how make ctags give tag addresses as a line number, rather than a search command?
That documentation is only for the changes introduced by universal ctags. What you're looking for is the documentation for exuberant ctags:
−−excmd=type
Determines the type of EX command used to locate tags in the source file. [Ignored in etags mode]
Which can also be achieved with -n.
I've written a program that returns keycodes as integers for DOS
but i don't know how to get it's output as a variable.
Note: I'm using MS-DOS 7 / Windows 98, so i can't use FOR /F or SET /P
Does anyone know how i could do that?
A few solutions are described by Eric Pement here. However, for older versions of cmd the author was forced to use external tools.
For example, program tools like STRINGS by Douglas Boling, allows for following code:
echo Greetings! | STRINGS hi=ASK # puts "Greetings!" into %hi%
Same goes for ASET by Richard Breuer:
echo Greetings! | ASET hi=line # puts "Greetings!" into %hi%
One of alternative pure DOS solutions needs the program output to be redirected to the file (named ANSWER.DAT in example below) and then uses a specially prepared batch file. To cite the aforementioned page:
[I]n the batch file we need to be able to issue the command
set MYVAR={the contents of ANSWER.DAT go here}. This is a difficult task, since MS-DOS doesn't offer an easy way to prepend "set MYVAR=" to a file [...]
Normal DOS text files and batch files end all lines with two consecutive bytes: a carriage return (Ctrl-M, hex 0D, or ASCII 13) and a linefeed (Ctrl-J, hex 0A or ASCII 10). In the batch file, you must be able to embed a Ctrl-J in the middle of a line.
Many text editors have a way to do this: via a Ctrl-P followed by Ctrl-J (DOS EDIT with Win95/98, VDE), via a Ctrl-Q prefix (Emacs, PFE), via direct entry with ALT and the numeric keypad (QEdit, Multi-Edit), or via a designated function key (Boxer). Other editors absolutely will not support this (Notepad, Editpad, EDIT from MS-DOS 6.22 or earlier; VIM can insert a linefeed only in binary mode, but not in its normal text mode).
If you can do it, your batch file might look like this:
#echo off
:: assume that the datafile exists already in ANSWER.DAT
echo set myvar=^J | find "set" >PREFIX.DAT
copy PREFIX.DAT+ANSWER.DAT VARIAB.BAT
call VARIAB.BAT
echo Success! The value of myvar is: [%myvar%].
:: erase temp files ...
for %%f in (PREFIX.DAT ANSWER.DAT VARIAB.BAT) do del %%f >NUL
Where you see the ^J on line 3 above, the linefeed should be embedded at that point. Your editor may display it as a square box with an embedded circle.
I have a problem reading ASCII-Files into Origin9.1. My ASCII-File looks like below: (note that I have 1 space before , 2 spaces between and 1 space after the numbers)
C:\amiX_TimeHist_P1.dat:
0,19325E-02 0,10000E+00
0,97679E-11 0,99997E-11
0,19769E+10 0,10025E+00
0,39169E+00 0,11636E+00
0,47918E+00 0,13156E+00
later I want to do the following with a scr-File but for now I write the following in Origin2015 in the Script-LabTalk-window:
open -w C:\amiX_TimeHist_P1.dat;
That command works but the numbers I get are in a wrong format:
When I read the file with the Import-wizzard or with ASCII-Import I can choose several options to fit the numbers correctly in the my columns. But this has to be done automatically.
Is there a way to read an ASCII-File uncluding setting parameters when using a script?
Instead of open you should use impASC to import ASCII data. Then you can specify some options to the command. In your case the following should work:
impASC fname:=C:\amiX_TimeHist_P1.dat options.FileStruct.DataStruct:=2 options.FileStruct.MultipleDelimiters:=" " options.FileStruct.NumericSeparator:=1;
If you just type impASC in your script window, in the following dialog box you can edit the import options and display the corresponding skript command.
I am trying to concatenate a set of .txt files using windows command line, into a csv file.
so i use
type *.txt > me_new_file.csv
but a the fields of a given row, which is tab delimited, ends up in one column. How do I take advantage of tab separation in the original text file to create a csv file such that fields are aligned in columns correctly, using one or more command lines? I am thinking there might be something like...
type *.txt > me_new_file.csv delim= ' '
but haven't been able to find anything yet.
Thank You for your help. Would also appreciate if someone could direct me to a related answer.
From the command line you'd have a fairly complicated time of it. The Windows cmd.exe command processor is much, much simpler than dash, ash, or bash, et.al.
Best thing would be to concatenate all of your files into the .csv file, open it in a text editor, and do a global find and replace replacing with ,
Be careful that your other data doesn't have any commas in it.
If the source files are tab delimited, then the output file is also tab delimited. Depending on the software you are using, you should be able load the tab delimited data properly.
Suppose you are using Excel. If the output file has a .csv extension, then Excel will default to comma delimited columns when it opens the file. Of course that does not work for you. But if you rename the file to have some other extension like .txt, then when you open it with Excel, it will open a series of dialog boxes where you can specify the format, including tab delimited.
If you want to keep the .csv extension and have Excel automatically open it properly, then you need to transform the data. This can be done very easily with JREPL.BAT - a hybrid JScript/batch utility that performs a regular expression search and replace on text data. JREPL.BAT is pure script that runs natively on any Windows machine from XP onward.
The following encloses each value in quotes, just in case a value contains a comma literal.
type *.txt 2>nul | jrepl "\t" "\q,\q" /x /jendln "$txt='\x22'+$txt+'\x22'" /o output.csv
Beware: Your use of type *.txt will fail if the last line in any of your source .txt files does not end with a newline. In such a case, the first line of the next file will be appended to the last line of the previous file. Not good.
You can solve that problem by processing each file individually in a FOR loop.
(for %F in (*.txt) do jrepl "\t" "\q,\q" /x /jendln "$txt='\x22'+$txt+'\x22'" /f "%F") >output.csv
The above is designed to run on the command line. If used in a batch script, then a few changes are needed:
(for %%F in (*.txt) do call jrepl "\t" "\q,\q" /x /jendln "$txt='\x22'+$txt+'\x22'" /f "%%F") >output.csv
Note: My answer assumes none of the source files contain quotes. If they do contain quotes, then a more complicated search and replace is required. But it still can be done efficiently with JREPL.
This is a common issue I have and my solution is a bit brash. So I'm looking for a quick fix and explanation of the problem.
The problem is that when I decide to save a spreadsheet in excel (mac 2011) as a tab delimited file it seems to do it perfectly fine. Until I try to parse the file line by line using Perl. For some reason it slurps the whole document in one line.
My brutish solution is to open the file in a web browser and copy and paste the information into the tab delimited file in TextEdit (I never use rich text format). I tried introducing a newline in the end of the file before doing this fix and it does not resolve the issue.
What's going on here? An explanation would be appreciated.
~Thanks!~
The problem is the actual character codes that define new lines on different systems. Windows systems commonly use a CarriageReturn+LineFeed (CRLF) and *NIX systems use only a LineFeed (LF).
These characters can be represented in RegEx as \r\n or \n (respectively).
Sometimes, to hash through a text file, you need to parse New Line characters. Try this for DOS-to-UNIX in perl:
perl -pi -e 's/\r\n/\n/g' input.file
or, for UNIX-to-DOS using sed:
$ sed 's/$'"/`echo \\\r`/" input.txt > output.txt
or, for DOS-to-UNIX using sed:
$ sed 's/^M$//' input.txt > output.txt
Found a pretty simple solution to this. Copy data from Excel to clipboard, paste it into a google spreadsheet. Download google spreadsheet file as a 'tab-separated values .tsv'. This gets around the problem and you have tab delimiters with an end of line for each line.
Yet another solution ...
for a tab-delimited file, save the document as a Windows Formatted Text (.txt) file type
for a comma-separated file, save the document as a `Windows Comma Separated (.csv)' file type
Perl has a useful regex pattern \R which will match any common line ending. It actually matches any vertical whitespace -- the same as \v -- or the CR LF combination, so it's the same as \r\n|\v
This is useful here because you can slurp your entire file into a single scalar and then split /\R/, which will give you a list of file records, already chomped (if you want to keep the line terminators you can split /\R\K/ instead
Another option is the PerlIO::eol module. It provides a new Perl IO layer that will normalize line endings no matter what the contents of the file are
Once you have loaded the module with use PerlIO::eol you can use it in an open statement
open my $fh, '<:eol(LF)', 'myfile.tsv' or die $!;
or you can use the open pragma to set it as the default layer for all input file handles
use open IN => ':raw:eol(LF)';
which will work fine with an input file from any platform