There are some special characters in my .xls file. I am trying to read all lines in .xls and write them into .txt file, but characters are changed. For example: There are ós in the Excel.
TCL Script:
set Channel_Read [open Sample.xls r]
set Channel_Write [open Text.txt a+]
while {[gets $Channel_Read Line]>=0} {
puts $Channel_Write $Line
}
close $Channel_Write
close $Channel_Read
After I open Text.txt, ó is changed to \&\#243;.
Any idea how to avoid this?
The immediate points:
The .xls format is binary, so you should use:
set Channel_Read [open "Sample.xls" rb]
(Or fconfigure $Channel_Read -translation binary straight after opening; it's equivalent.)
Similarly, if you're dumping it to another file, using a+b as the open mode for that — for the same sorts of reasons — will stop output mangling.
For a straight copy from one channel to another, use fcopy instead of a loop. The fcopy command uses some low-level tricks to do things more efficiently.
fcopy $Channel_Read $Channel_Write
However, I really suspect that something is going on other than is directly revealed in the information that you provide. Tcl wouldn't mangle bytes in the way you describe (I know what the encoding engine is doing, and it doesn't work that way for any encoding). What's more, the concept of a “line” in relation to a spreadsheet is distinctly off; spreadsheets don't have lines, they have rows (and columns, and sheets) and they don't need to be arranged in the same way at all. I also fail to see why appending a binary spreadsheet to another file would be a good thing to do.
I think you need to stop, think about the wider task that you are trying to do, and then try to solve that rather than just this little piece. While I could answer your immediate questions in more depth, I suspect that I'd not be giving you genuinely helpful assistance if I did.
No need to reinvent the wheel. Use the TCOM package, which is designed for exactly what you're trying to do. Here are some examples: Tcom examples for Microsoft Excel
Related
I'm interested in simply adding a comment next to my files in Linux (Ubuntu). An example would be:
info user ... my_data.csv Raw data which was sent to me.
info user ... my_data_cleaned.csv Raw data with duplicates filtered.
info user ... my_data_top10.csv Cleaned data with only top 10 values selected for each ID.
So sort of the way you can comment commits in Git. I don't particularly care about searching on these tags, filtering them etc. Just seeings them when I list files in a directory. Bonus if the comments/tags follow the document around as I copy or move it.
Most filesystem types support extended attributes where you could store comments.
So for example to create a comment on "foo.file":
xattr -w user.comment "This is a comment" foo.file
The attributes can be copied/moved with the file just be aware that many utilities require special options to copy the extended attributes.
Then to list files with comments use a script or program that grabs the extended attribute. Here is a simple example to use as a starting point, it just lists the files in the current directory:
#!/bin/sh
ls -1 | while read -r FILE; do
comment=`xattr -p user.comment "$FILE" 2>/dev/null`
if [ -n "$comment" ]; then
echo "$FILE Comment: $comment"
else
echo "$FILE"
fi
done
The xattr command is really slow and poorly written (it doesn't even return error status) so I suggest something else if possible. Use setfattr and getfattr in a more complex script than what I have provided. Or maybe a custom ls command that is aware of the user.comment attribute.
This is a moderately serious challenge. Basically, you want to add attributes to files, keep the attributes when the file is copied or moved, and then modify ls to display the values of these attributes.
So, here's how I would attack the problem.
1) Store the information in a sqlLite database. You can probably get away with one table. The table should contain the complete path to the file, and your comment. I'd name the database something like ~/.dirinfo/dirinfo.db. I'd store it in a subfolder, because you may find later on that you need other information in this folder. It'd be nice to use inodes rather than pathnames, but they change too frequently. Still, you might be able to do something where you store both the inode and the pathname, and retrieve by pathname only if the retrieval by inode fails, in which case you'd then update the inode information.
2) write a bash script to create/read/update/delete the comment for a given file.
3) Write another bash function or script that works with ls. I wouldn't call it "ls" though, because you don't want to mess with all the command line options that are available to ls. You're going to be calling ls always as ls -1 in your script, possibly with some sort options, such as -t and/or -r. Anyway, your script will call ls -1 and loop through the output, displaying the file name, and the comment, which you'll look up using the script from 2). You may also want to add file size, but that's up to you.
4) write functions to replace mv and cp (and ln??). These would be wrapper functions that would update the information in your table, and then call the regular Unix versions of these commands, passing along any arguments received by the functions (i.e. "$#"). If you're really paranoid, you'd also do it for things like scp, which can be used (inefficiently) to copy files locally. Still, it's unlikely you'll catch all the possibilities. What if someone else does a mv on your file, who doesn't have the function you have? What if some script moves the file by calling /bin/mv? You can't easily get around these kinds of issues.
Or if you really wanted to get adventurous, you'd write some C/C++ code to do this. It'd be faster, and honestly not all that much more challenging, provided you understand fork() and exec(). I can't recall whether sqlite has a C API. I assume it does. You'd have to tangle with that, too, but since you only have one database, and one table, that shouldn't be too challenging.
You could do it in perl, too, but I'm not sure that it would be that much easier in perl, than in bash. Your actual code isn't that complex, and you're not likely to be doing any crazy regex stuff or string manipulations. There are just lots of small pieces to fit together.
Doing all of this is much more work than should be expected for a person answering a question here, but I've given you the overall design. Implementing it should be relatively easy if you follow the design above and can live with the constraints.
I'm making a file monitor for a folder where I download subtitles. So far, it works like this:
Look for new .rar files in the folder.
If found, extract the subtitles and delete the .rar file
If a single .srt file was extracted, save the file name to a variable.
Now, I'm clueless about how to achieve the next (and final) part of the script:
I want to find a pattern based on the way subtitles are named.
Let's say, the subtitles file can be something like this:
SomeShow.1x03.stuff.srt
some_show s01e03-stuff.srt
some show 1-03 stuff.srt
etc.
I want to get something like: SomeShow 1 3 and based on that, start the video with the name that matches that pattern, which I guess would be a matter of reversing the process that was used to get the Show, season and episode based on the name of the .srt file.
Is this possible at all? It'd be really simple stuff in most languages, but I really need this to be a .bat and I'm clueless about how to approach this... so far all I've managed to do is to remove the extension from the variable.
Thanks in advance.
Batch files are Turing complete - you can do anything in them, but it is usually not wise to go to extremes. You might be able to package a sed or grep or your own binary alongside your .bat file for a good compromise between batchiness and function. If you can assume a suitable operating system, you will have Powershell installed and go that route.
You should recognize that the task is not exactly defined and that the "solution" may need some tweaking and be never robust enough.
For this reason, the richer language you can pick, the further you will get.
I have an excel sheet with the following columns for a stock chart:
Open
High
Low
Close
Day Average
How do i use Fortran to pull only the "Day Average" from the excel file?
I am new to Fortran and haven't been able to find anything that could help except for the link below but its pretty difficult for me to grasp since i am looking for something different than what the link is showing me:
http://en.wikibooks.org/wiki/Fortran/Fortran_simple_input_and_output
No, contrary to the other answers CSV is not the easiest file to read. Go to File/Save as/Other Formats and save it as Formatted text (space delimited). Depending on your locale, you will either have a comma or a full stop as a decimal point, so you'll have to (either use an external editor to do a simple search/replace) or write a fortran subroutine that goes character by character, and replaces every comma with a full stop.
After that it's easy, no ;'s to parse, so you just
program FreeFormat
real(4), dimension(5) :: open, high, low, close, dayaverage
real(4) :: average
open(unit=1, file='filename.prn', status='old')
do i=1,5
read(1,*)open(i), high(i), low(i), close(i), dayaverage(i)
enddo
average = sum(dayaverage)/5
write(*,'("Average is",f5.2)')average
end program FreeFormat
You get the point ...
Here are a few links to get you started (Excel/Fortran DLL related) ...
Trouble with file location in excel/fortran dll connection
Fortran DLL & MS Excel
The native binary format of an Excel file will be very difficult to parse. Export the file to text or CSV, as already suggested. CSV will probably be easiest. You probably want to use "list directed IO", which has the source form:
read (unit-number, *) format-items
Fortran list-directed IO will read into the variables in the list "format-items" is a very flexible manner. The items in the file should be separated by deliminators such as spaces or commas. For your case, have five variables corresponding to the five columns in order to reach the 5th one that you want. Fortran is record-oriented, so you do one read per line.
You'll have to read and parse the Excel file in Fortran to get the values you want. If you are new to the language then this might be very hard to do. Maybe it's easier to save the Excel sheet in a CSV format and parse that? Good luck!
If someone sends me a document (.pdf,.doc,.xls, ppt, .ogg, mp3, png, etc) without the extension, how can I determine the file type? The /usr/bin/file command doesn't always guess right or it simply says that I have a Microsoft Office document. I would like to know exactly so I can add the extension to the file name.
You can come up with your own rules by adding them to /etc/magic
man file for more details. It is tricky to always get these correct however, I have had reasonable success.
Try mimetype(1).
For Perl, look at File::MimeInfo.
Some of the other posters thus far appear to neglect a few things.
File::MimeInfo uses the same MimeInfo database used by 'file' to identify files. So That's unlikely to do anything different.
File::Type is likely to be interesting though, as it relies only on itself, but this leads to a comically long script full of 'if' statements. But this is, by its very nature, unlikely to cover things 'file' already doesn't cover.
The best you can do with unknown filetypes is try cracking them open with a hex-editor, or running them through 'strings' and seeing if you recognise anything. If you manage how to Identify a file, you may wish to go for File::Type as your solution because as far as I can make out, its at least easy to extend.
You can use the Perl module: File::Type
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)