I have a little script on Centos 6.5 64 bit which sends email content of a text file (as inline and NOT as attachment) to a user:
mail -s "Zabbix Alerts" -r sender#mydomain.com receiver#mydomain.com < /filename
It used to work great for a long time. Today we have got a new server Centos 6.7 64bit and the same scripts sends what is expected but not as inline but as attachment.
We need the content of the text file as inline text (not attachment).
I have already spent a few hours find the cause but no luck.
I will be really thankful if someone can help me.
I just found it is some problem with the text file. When I open it in vi it shows too many ^M characters. When I remove that it becomes fine. So it is not a problem with mail but the file
Related
I have made a small (8 MB) program into a MAC executable (.app?)
It works great if I share it using a thumbstick, but if I try to upload it to google drive and then download it it doesn't work. By this I mean It first tells me that It is an unidentified source (this seems reasonable)
But then if I click "open"
It opens as a text file with junk data:
If I try to force it to open on the terminal, how the other program opens, it just shows the heartbeat thing that MACs do when opening a file, but never opens anything.
It is certifiably the same exact file. Same size, same name, same goobldygoop if I open both of them as text files instead of executables.
I am really confused, the only thing I can think of is the "signature" that apple uses is lost when it is compressed into a zip, but I'm probably totally off base.
The code uses python 3.7, pyinstaller, pynput, and selenium.
I am using MAC OS Catalina to write and make into an EXE, then another Catalina to try to run the program.
EDIT: Clarify what doesn't work means
Please help.
I found the answer, simply zip the file from my mac and send it that way!
Yay!
This is such a basic question I am surprised I could not easily find an answer to it:
I use Notepad++ to write my scripts in. Someone sent me some code for a shell script (.sh) that I could modify to suit my needs. I simply changed a small bit of text using Notepad++ (on Windows) and used FileZilla (SFTP) to upload it to my server (Debian Linux).
There were a few problems with this that it took my server admin an hour to find, namely:
FileZilla, for whatever reason, defaults to ASCII rather than binary! (changed it to binary and removed the .sh association with ASCII)
The permissions were wrong, chmod took care of this
Problem is it STILL did not work. To fix it my server admin simply copied the text right on the server (using vim or nano) into a new shell script file and saved that. Before he kept saying the problem was Windows (which he loves to hate on) but it seems it is the encoding that text-editors are using that is corrupting the files.
He said my text-editor encoding needs to be said to "None". However, that is not an option - only ANSI, UTF and UTS variants are options!
How can I create a shell script on Windows with no encoding whatsoever so that it doesn't get corrupted?
I need to be able to simply transfer the file to the server, I can't mess around with modifying it once on the server which is wholly impractical.
To fix it EndOfLine and encoding on Notepad++ :
On the bottom right of Notepad++ you can right click on the left of the encoding "UTF-8" and click on Convert UNIX(LF) format. Be sure to change encoding to UTF-8 if it is not the case.
In Filezilla :
Transfert mode : auto
I have a very strange problem..
perl5 Number Sign # not working correctly for comments..
We use emperl, mod_perl, apache, linux..
In some programs if I have a line commented out with a number sign # or just a number sign # by itself on a line, all of the code below that line doesn't work correctly.
There is a sysadmin so I don't have access or control over any of the settings on the server.
This is a new issue everything always worked previously.
So many possible area's that this might be coming from that I'm checking to see if anybody has run across this..
Any suggestions?
Found the issue:
Was transferring the files from LINUX to Windows to edit them.
If the file was originally created in Windows the end of a line was just a <CR> and for some reason the whole file wasn't running right. It mainly showed up when using the hash symbol for perl comments.
When I made sure the files had end of lines with <CR><LF>, this solved this issue.
I'm on CentOS 6, and I'm playing around with the Pre-Login file message, located here:
# vi /etc/issue
I want to add some custom text of mine, and colorizing that text.
Here's my file text for now:
----------------------------
Welcome to my Testing Server
----------------------------
I've used an example from a friend of mine, on his CentOS 5:
----------------------------
^[[47;31m Welcome to my Testing Server ^[[0m
----------------------------
I see it working fine on his box, as I ssh to it.
But I copied and pasted it into my /etc/issue file and it returns everything as text.
Am I missing something?
The ^[ is not a literal carat followed by a bracket, it is a control character. When copying from your friend's box to yours, the control characters have been taken literally and cease to work properly, see this for more information on colorizing /etc/issue
Im using Liferay portal server on tomcat and Linux Ubuntu.
Liferay is generating a file that is very long. I've seen those files in windows and its working. But when i tried running it in ubuntu, it doesn't create the file and my server is giving me error. I've also tried to make a file with a very long filename and it really doesn't allow me.
Is there a way for Linux Ubuntu to allow me to do this?
Fix this...
The source of my problem is the encrypted home of my ubuntu OS. It seems that the filename of the file created is also encrypted making my long filename even longer.
When i made a new installation of my Ubuntu, i didn't encrypt my home anymore and it works fine now.. thanks a lot all...
There's a huge slew of reasons it may not be working, probably the least of which is a long file name (unless we're talking about a filename over 255 characters, which I believe is the hard-limit).
Also, file length isn't going to be a big problem unless you've got some truly enormous files (sometimes linux filesystems cap at 2GB, but I don't know what the behaviour is if you went over. You'd probably still see a 2GB file that just doesn't contain everything).
My knee-jerk reaction would be to say you're having a permissions problem where the user the server is running as (say, 'www' or 'www-data', or whatever) doesn't have permission to write in the folder its trying too.
The filename you have given as an example is fine:
kevin#latte:~/miscdev/j$ touch 'everything.jsp_Q_browserId=firefox&themeId=controlpanel&colorSchemeId=01&minifierType=js&minifierBundleId=javascript.everything.files&t=1249034302000'
kevin#latte:~/miscdev/j$ ls -l
total 0
-rw-r--r-- 1 kevin kevin 0 2009-07-30 17:07 everything.jsp_Q_browserId=firefox&themeId=controlpanel&colorSchemeId=01&minifierType=js&minifierBundleId=javascript.everything.files&t=1249034302000
I imagine the problem is that you are passing that filename to a shell un-escaped, and it is interpreting the & character. Put the filename in single-quotes, as I have in my example.
I had the same problem on my Ubuntu 9.10 machine and I think it really was caused by the home-directory encryption. Those "too long" filenames work fine outside my home.