I ran the "file" command on two identical machines running the same OS and on the same file, but on one machine it identified the file type as "rtf" and on the other as just "data". Can anyone help me figure out why this might be happening?
Found the issue. The magic.mgc file was different.
Related
I have a batch that integrates an xml file time to time but could happens daily. After it integrates it puts in a folder like /archives/YYMMDD(current day). The problem is if the same file is integrated twice. So I need a script what verifys the file (with diff command its possible but risky to make a bottleneck) but the problem is I can't find to resolve how to make to give the second files location.
P.S. I can't install on the server anything.
Thanks in advance.
I am trying to debug an application that is cross-compiled on a Windows host for a Linux target.
The problem:
Because the initial compilation is in windows the stored source file paths in the binary is of the form C:\Users\foo\project\.... On the Linux target I have put the source files under \home\foo\project\.... By default gdb does not find the source file because of the different path.
What I have tried so far:
Use "directory" command in gdb to give an exact path for the .c source file in the target Linux system where the app is being debugged. This works but unfortunately there are literally hundreds of files so this solution is unrealistic.
Use the set substitute-path C:\\Users\\foo\\project /home/foo/project command to have gdb substitute all prefixes. Note that the \\ seems necessary such that show substitute-path registers the right string. This unfortunately does not work. My guess is that the substitute-path command does not handle ms-dos style paths.
Tried separating the debug info out into a separate .debug file (see How to generate gcc debug symbol outside the build target?) and then using debugedit to change the paths with the command debugedit --base-dir=C:\Users\foo --dest-dir=/home/foo project.debug. Unfortunately this does not work either. debugedit seems to work fine if the existing path is all UNIX/Linux like but doesn't seem to work with ms-dos style paths.
I have looked around stackoverflow and while there are similar topics I can't find anything that will help me. Would really appreciate any suggestions/help. I realize that cross compiling from Windows is a very roundabout way but can't avoid that for the moment.
Thanks
Although it's rather old question, I did encountered the same problem. I managed to resolve it but using sed on binary executable... (yeah, a 'bit' hack-ish, but did not found another way). With sed I've managed to replace symbols paths right inside the executable, the trick is that new path's length should be the same as the old one.
sed -i "s#C:/srcpath#/srcpath/.#g" ./executable
Be sure to make new path the same length, otherwise the executable will brake.
I also have this same problem. Your option 1 isn't as bad as you think because you can script creating all the 'directory' commands with something like this python code:
def get_directory_paths():
return_array = list()
unix_path = os.path.join('my','unix','path')
for root, dirs, files in os.walk(unix_path):
for dir in dirs:
full_unix_path = os.path.join(root,dir)
escaped_unix_path = re.sub("\s", "\\\\ ", full_unix_path)
return_array.insert(0, "directory " + escaped_unix_path)
return '\n'.join(return_array)
The downside is that if you have two source files with the same name in different directories, I don't think gcc can pick the right one. That worries me, but in my particular situation, I think I'm safe.
For option 2 (which I suspect would fix the aliasing condition from #1), I think the problem is that the substitutions are not ending with a "file separator" according to the linux so they aren't applied:
To avoid unexpected substitution results, a rule is applied only if the from part of the directory name ends at a directory separator. For instance, a rule substituting /usr/source into /mnt/cross will be applied to /usr/source/foo-1.0 but not to /usr/sourceware/foo-2.0. And because the substitution is applied only at the beginning of the directory name, this rule will not be applied to /root/usr/source/baz.c either." (from https://sourceware.org/gdb/current/onlinedocs/gdb/Source-Path.html#index-set-substitute_002dpath )
I haven't tried anything like your #3 and I also considered something like #dragn suggestion, but in my situation the paths are not even close to the same length, so that will be an issue.
I think I'm stuck with #1 and a script, but if anyone has other suggestions, I'm interested options :-)
I have been getting the following error while opening a .vtk file in Paraview:
"Error reading ascii data. Possible mismatch of datasize with declaration."
I am running a simulation on my Mac OS X 10.9.3, and saving my solution files in .vtk format. While the initial solution file (at time t=0) opens perfectly, the above error occurs with the next few solution files. Moreover, some of my scalar variables disappear from the data-set in Paraview. I tried opening the file on my friends laptop, which has a Linux OS, and Paraview opens all the files correctly with all variables in place. I noticed a similar problem while using VisIT.
I have even tried to use different versions of Paraview but the problem persists. Could there be a problem with the vtkreader? Any help or leads to solving this issue will be much appreciated.
PS: I have found a similar post on this forum, but no one seems to have replied to it yet:
Paraview "possible mismatch of datasize with declaration" error
Your file declares 70970 points although I think that it has 70971.
Your file declares 140760 cells although I think that it has 140761.
I am using Komodo edit 7.1 on a macbook pro running OS X mountain lion
Note that the duplicated file needs a space at the beginning. e.g:
to execute hello-world.py, I wrote the code given in the lesson but when running the command i get an error
/bin/sh: /usr/bin/pythonhello-world.py: No such file or directory.
When I create a file name: _hello-world.py (the underscore is actually white space) and execute it from there, the command completes the action correctly
'/usr/bin/python hello-world.py' returned 0.
Interestingly enough, the code for the duplicated file can be blank, somehow it is choosing the proper file.
p.s. obviously I am brand new at this. I have searched google for similar problems but haven't found what I need. Please help!
Thank you
The path to the python executable is not setup correctly. Use the Terminal to fix it.
Got a strange problem with Antenna - I've recently switched over to a new laptop, and now when I copied my build setup across to it it started exhibiting strange behaviour. When I call wtkpackage (in a way that worked perfectly fine on the old laptop with exactly the same codebase), the generated JAR file contains two META-INF/MANIFEST.MF files (yes, exactly the same file path). These seem to have the same contents, and from the output from the command-line unzip tool (unzip -l myscrewedup.jar) one appears at the start of the file, one at the end. I've tried adding the duplicates="fail" attribute to the package command, but with no joy.
Has anyone else encountered this? If so, did you find a solution?
Better answer this one in case anyone else does encounter the same problem. The problem was with the Ubunutu 11.04 setup I was using on the new laptop - for some inexplicable reason, the jar command was linked to fastjar, a C implementation of jar which evidently doesn't work properly. Switching this over to the standard Sun implementation fixed the problem immediately.