Hi,
"dos2unix" and "unix2dos" commands are there to change the file type according to the environment.
I hope this will help you.
Regards,
Alok
Unix files being converted to Windows format
We are using Telelogic Synergy Release 6.5.4096 running with Windows XP and Windows 7. When we archive Unix formatted files into a Synergy project, the file format gets converted to Windows/DOS (carriage return added).
Is there any way to prevent that from happening?
We'd like to keep our Unix files in that format, and our Windows files in that format. I don't see an option to set.
Thanks, Mike
Tags:
6 Answers
Hi Mike,
If you are using Synergy on a Unix server, the ascii cache and archive files on that Unix server are normally in Unix text format. When you use a Windows client, and have the work area properties for a project set to translate newlines, the ascii files are converted to Windows text format when copied from the Unix server to the Windows file system, and conversely converted from Windows text format to Unix when copying from a Windows work area to the Synergy database on the Unix server.
If you want to prevent that newline translation, you can turn ff the translate newlines in your Windows work area. However, be aware that this will mean that a file in Windows text format will be copied to the Synergy database witout conversion, and if that file appears in a Unix hosted work area, it will appear in Windows text format not Unix. Some Unix tools are intolerant of the extra carriage returns.
You can also use Synergy types that are considered binary. Files that are of binary Synergy type (or subtype), or that have been scanned and found to contain binary characters, are treated s binary and do not have newline translation or keyword expansion performed.
Regards,
David.
That's what I do now, and was hoping to avoid that in the first place.
Some of our users would be bothered by having to convert the files.
--Mike
David,
Thanks for the detailed reply.
I believe that our Synergy server is Unix based.
The basic problem is that Windows formatted script and Python files do not run well (i.e. not at all) on a Unix system.
Some of our users would be frustrated by having to do a file conversion.
Turning off the translate newlines would have to be done by each member of the project who modifies those files. That's probably workable for our team, but could be undone inadvertently at some time.
So, I'm wondering about forcing individual files to have the proper format from the start.
Followup questions, please:
1. If I were to put a non-ascii binary character in a .txt or .sh file, for example, will Synergy keep the file as binary format even if that character is removed later?
2. Can I force, in some other way, a .txt or .sh file (or whatever) to be stored as a binary file regardless of what the file extension is, and regardless of whether the contents are regular ascii?
Thanks again,
Mike
Hi Mike,
The first thing I would check is that as seen on the Unix server, the cache file is using Unix EOL (end of line) representation - that is, lines are terminated by newline (<LF>) and not by <CR><LF>. If the files in the Unix-hosted database are using Windows EOL representation, then a user made an error in getting those files into the Synergy database. This might have occurred if they were using a Windows client and any of the following were true:
1. ]The project work area had "translate newlines[" turned off.
2. The file was created using a Synergy type of binary or one of its subtypes.
3. The file contained binary characters (such as <NUL>) such that the file contents were treated as binary. For a checked in file, the "handle_source_as" attribute would then be set to binary and the contents would never have newline translation or keyword expansion performed.
4. If the cache file is using Windows EOL format, then that's the problem. It will mean that on Unix work areas, the file will be in that format regardless of whether you use copy-based or link-based work areas. In order to fix this, you will have to check out the file, then use something like dos2unix (as suggested by Alok) on your Unix server to convert the file contents from Windows EOL representation to Unix EOL representation, ensuring that the file is using the Synergy type ascii or one of its subtypes, and ensuring that the file does not contain any binary characters, especially <NUL> or <CTRL-Z>.
Once you have the cache files on your Unix server using Unix EOL representation, they will always use that EOL representation in Unix client work areas. On Windows client work areas, users should use a work area whose "translate newlines" is enabled. This is the default when creating or copying a project using a Windows client. The result will be that when the Unix EOL format files are copied to such Windows work areas, they will be translated to Windows EOL format.
If you have files that you never want to be EOL translated, then you can use a Synergy type for that file that is binary or one of its subtypes. However, note that in doing so, you are saying that the contents of the file are always to be treated as binary. This means no EOL translation, no keyword expansion, and (in 7.2 onwards) no encoding conversion. For source code files, especially where you want to use Synergy keywords, this is probably not a good choice.
Regards,
David.
David,
Thanks for the information.
Since we want keyword substitution, using a binary file type won't work.
After more experiments with checking-out/in files, it appears that we'll need to do the Unix format conversion after extracting from the Synergy project, which always yields a DOS formatted file.
We're not using Synergy on the Unix systems that need the script files, so we use network file copying (WinSCP, shared drives).
Thanks for the explanations about Synergy. That is useful.
--Mike
CMCrossroads is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.