I find it very convenient to update my website using Virtualmin’s File Manager.
However, I sometimes have to update a Perl CGI script or a text data file used in the script, and so required to upload the file as TEXT and not as BINARY. As I couldn’t find such option in the file manager, I have to use FTP software through Wireguard.
It would be great if “uploading as text” option would be added to the built-in file manager.
I frequently upload text files (plain text, code/script files) and use File Manager without any problem. So I don’t understand why yours are having a problem?
I do not know the technical aspects, but a perl cgi program on unix must be uploaded as “text” and not as “binary” in order to be executed. This is why every FTP program has those two options for the upload. I noticed there is no problem with HTML nowadays and this is why I use the file manager to upload those. I found the database files read by perl (which are plain text in my case) also must be uploaded as “text” or produce a variety of strange signs when read by the program.
I believe this has come up before. Maybe encoding? I thought it would be taken care of in an update. Maybe that update hasn’t happened or it didn’t work?
I am up loading from windows PC to Unix (Ubuntu 22.04) VMs. and as I said I have no problem uploading any file (HTML, CSS, Perl / Javascript / Bash / Plain Text Notes ) I also upload database backup files and even Go exe files they all seem to upload without any problems. I also use local gziped files and even they upload and unzip (as long as you remember to tick the box) So cannot understand why you are seeing a problem.
I guess the problem is you’ve got Windows or Mac line endings in your files?
Modern text editors are smart enough to be able to load and save any format, so just choose to use the right format (with Linux/UNIX line ends).
FTP historically had that because when FTP was commonly used, there were still many text formats and it may have needed to translate between major differences (like encodings), not just line endings.
Ideally uploading in the file manager would never change anything in the file. I could maybe see an argument for adding a “Convert Line Endings” option somewhere, but I wouldn’t want to see a Text/Binary mode, as it’s very rarely needed (most developers have their editor configured to save files in the format that works on the systems where they are deploying).
ASCII type is used to transfer text files. The problem with text files is that different platforms have different kinds of line endings. Microsoft Windows for example uses a CR+LF pair (carriage return and line feed), while Unix(-like) systems, including Linux and MacOS X, only use LF and traditional MacOS systems (MacOS 9 or older) only use CR. The purpose of ASCII type is to ensure that line endings are properly changed to what is right on the platform. According to the FTP specification, ASCII files are always transferred using a CR+LF pair as line ending.
So in case the file is transferred from the client to the server, the client has to make sure CR+LF is used. Therefore it has to add nothing (on Microsoft Windows), add CR (on Unix) or add LF (on legacy MacOS) to each line ending. The server then adjusts the line ending again to what is used on the platform the server runs at. If it is Microsoft Windows, nothing has to be removed, while on Unix the superfluous CR is removed and on legacy MacOS the unneeded LF.
I will have a play uploading various files from my Windows PC tomorrow and see what happens. I always use my FTP software in binary mode .
As I mentioned, as long as your editor is configured to use appropriate line endings for the deployment system, everything will be fine. The files don’t need to change. Modern editors will detect the line ends when you open the file and won’t change them (unless explicitly told to do so).
There are tools for converting, as well (dos2unix, d2u), and of course tools like ex, sed, tr, etc. can also do the conversion. But, again, just tell your editor to use the right endings, and you’ll never have to think about it.
git can also be configured to convert line endings as data comes in and out.
does the file browser transfer in binary or ASCII mode is probably the quick question to ask. Then I don’t need to do any testing But I am guessing Binary.
File Manager is “binary”, and so is everything else that isn’t ancient (e.g. ssh/scp).
But, it doesn’t make sense to distinguish “text” or “binary” like this…it’s a weird accident of history and OS differences that is considered solved by using modern text editors that work with any line endings and can be configured to use the right ones for deployment…and since everything goes through git these days and git’s native line endings are Linux/UNIX, everyone now does everything with Linux/UNIX line endings…if you don’t already, you should.
I have not used this feature myself for a long time, but I believe Notepad++ (a free 3rd party Windows utility) has a ‘end of line’ setting as well as a converter button.
and several of our production RedHat servers have scripts using dos2unix
But I am guessing Binary.