WebRSH's Text Editor provides a mechanism for editing remote text files. It is implemented using the following simple idea: Files are "opened" by having their content inserted in a 'TEXTAREA' field of an HTML form. They are saved by submitting the form such that WebRSH overwrites the existing file with the submitted content.
While the idea is very simple, its implementation is not so trivial
and must be used with care. Otherwise, file corruption can easily
occur. A description of the potential problems, WebRSH's workarounds,
and detailed usage guidelines are given below. As initial guidelines
we should stress the following:
There are two ways to invoke the Editor: using the 'rshedit' command from the Command Line and clicking the 'Edit' button in the File Manager. In either of these methods the Editor would open with a blank file if no file is specified.
Usage should be straight forward. The 'Save' and 'Save As' buttons perform similarly to any other editor. 'Save+Exit' saves the file and exits the Editor while 'Exit' exits without saving. 'Reset' restores the Editor's content to the state it has been in when the form was last retrieved, namely, to its state following the last 'Save'/'Reload' operation. 'Reload' retrieves the file from disk and should have the same effect as 'Reset' unless the file had been modified from another Editor form or from another program. 'Options' invokes the Text Editor options setting form.
There are three general problems stemming from the way the Text Editor has been implemented. The first is an inevitable result of the cross-platform nature of web browsers along with the existence of different, platform-dependent, text formats. The other two can be attributed to the relatively loose way in which the HTML specifications define the 'TEXTAREA' tag--leading to different implementations among different web browsers. In principle, additional problems may also arise, and particular caution is recommended with any web browser that is NOT among the ones mentioned below.
The first problem arises from the fact that different operating systems use different conventions to denote end of a line in text files. (e.g., UNIX usually uses the single character LF, while WinDOS systems use the redundant two-character combo CR LF). Text editors have varying degrees of tolerance to dealing with non-native text files, and it is generally hard to determine the precise binary content of a file from the way it displays in any given editor. Web browsers are designed to accept text from many platforms, and they are thus willing to interpret a relatively wide variety of character combinations as denoting end of a line. When a form is submitted, however, browsers use a uniform convention to denote end of lines, and WebRSH saves the files as native text files. If the original file is a plain text file that was created using a native editor, it should not be modified when saved with WebRSH's Text Editor. Otherwise, the precise binary content of the file may very well be altered, although its "text content" shouldn't be. In many cases this conversion of text files to the native format should play a positive role. For example, text files that where imported from UNIX to Win32 and that do not display properly in 'Notepad' can be "fixed" by opening them in the Text Editor and then saving them. If, however, the precise binary content of a file is significant (as is surely the case with any file that is not a plain text file), saving the file with WebRSH's Text Editor is very likely to corrupt it--and should thus be avoided.
The second problem is the tendency of some web browsers to remove empty lines from text in 'TEXTAREA' tags. While MSIE 2.0,3.0x, NCSA Mosaic (3.0 for Windows), and Opera (tested with 3.21) do not remove any empty lines at all, Netscape Navigator, MSIE 4.0x, and Sun's HotJava would remove the first line of a file (if it is empty). More importantly, Lynx (2.6/2.7) would remove ALL empty lines, and it's hard to predict what other browsers might do. Since empty lines may often be important (e.g., they have special meaning in some code files such as TeX files), the Text Editor implements a special mechanism for protecting empty lines from being removed: A special configurable string ('Empty line Holder') is being appended to empty lines when files are opened with the Text Editor, and being removed (whenever it is the only content of a line) when files are saved. This mechanism can be disabled by setting 'Empty Line Holder' to be a null string. There is also an option to apply this protection mechanism only to the first line of a file (if it is empty)--a mode tailored to the behavior of most newer browsers. Note that using a non-null 'Empty Line Holder' shouldn't do any harm even if the browser doesn't require it as long as it is either a string which never occurs by itself on a line or a string whose removal would not matter (in the event that it does occur). In most cases, a single white space should make a good 'Empty Line Holder'. Since a white space on a line by itself is "invisible," it is very unlikely to ever have much significance. Thus, the removal of such spaces (in the event that they somehow occur) should not constitute any true damage to the file. Moreover, using such an "invisible" 'Empty Line Holder' would make the file appear in the Text Editor just as it would in other editors, making the protection mechanism unobstructive. The default (shipping) settings apply the protection mechanism only to the first line and have 'Empty Line Holder' set to a single white space. These settings should work well with most browsers, but need to be modified in some cases. In particular, they must be modified (to provide protection for all lines) when using some older versions of Lynx.
The third problem involves the issue of text encoding: Most browsers decode text in 'TEXTAREA' tags just as they would text in 'PRE' tags, namely, combinations of the form '&#nn;' would be interpreted as characters according to the ISO-8859-1 based 'HTML coded character set', and moreover, the special combinations '<', '>', '&', and '"' would be interpreted as '<', '>', '&', and '"' correspondingly. To insure correct interpretation of arbitrary text with such 'TEXTAREA'-decoding browsers, the text must be properly encoded ('<', '>', '&', and '"' are replaced by <', '>', '&', and '"'). Unfortunately, this decoding mechanism is not explicitly required (for 'TEXTAREA' tags) by the HTML specifications, and so some browsers (notably, NCSA Mosaic 3.0 for Windows) do not implement it and interpret any text within the 'TEXTAREA' tag explicitly. With such non-decoding browsers, encoding the text may lead to its corruption, while with 'TEXTAREA'-decoding browsers not encoding it may lead to its corruption. To permit use of WebRSH's Text Editor with either kind of browser, the Editor has an option to either encode or not. The default (shipping) setting is to encode, which is the proper mode for most browsers. This setting must be changed, however, when using a non-decoding browser. Since text in 'TEXTAREA' tags is being embedded in an HTML page, there is a problem if the text itself contains a '</TEXTAREA>' string when using a non-decoding browser. To resolve this issue (and allow editing of HTML files with any kind of browser) the Editor implements the following (optional) protection mechanism: Such strings are modified (when opening a file) by adding a configurable string ('</TEXTAREA> modifier') between the '<' and the '/'. This string is being removed from such tags when a file is saved. This mechanism is only being used when text encoding is disabled (it is automatically disabled if text encoding is enabled). To disable it completely, simply set '</TEXTAREA> modifier' to be a null string. In most cases, '/' should make a reasonable '</TEXTAREA> modifier'.