Layout overhoop bij simpel bourne shell scriptje

[Whizzer]

Langzaamaan begin ik nog gekker te worden dan ik al was... Het verhaal is simpel: via een simpel scriptje met een "vraag-antwoord spelletje" wil ik een linux server een configuratie voor een Cisco laten ophoesten en deze per mail versturen naar een emailadres. Een klein stukje:

code:

#!/bin/sh
echo "----------------------------"
echo "This template is for configuring a Cisco"
echo "----------------------------"
echo -en "Hostname of router: "; read DEVICEHOST
echo -en "Location of this device: "; read DEVICELOC
echo -en "Enter IP address and subnetmask of LAN interface (i.e. 10.0.0.1 255.0.0.0): "; read DEVICEIP

<...>

printf "
service timestamps debug datetime msec localtime show-timezone\r
service timestamps log datetime msec localtime show-timezone\r
service password-encryption\r
service compress-config\r
!\r
hostname $DEVICEHOST\r
!\r
boot-start-marker\r
boot-end-marker\r
!\r
card type e1 0 0\r
logging buffered 32768 debugging\r

<...>

end\r
" | mailx -s "config $DEVICEHOST" email.adress@domein

Zoals je ziet staat er overal \r achter om een carriage return te geven. Maar wat wil nu het geval, de mail lijkt zich er bar weinig van aan te trekken, want zo zie ik hem in mijn mailbox:

service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption service compress-config ! hostname asdf ! boot-start-marker boot-end-marker ! card type e1 0 0 logging buffered 32768 debugging


Maar wanneer ik hem naar een textfile redirect i.p.v. mailx, dan lijkt de \r goed te werken:

code:

[whizzer@server ~]$ more /tmp/bla.txt
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
service compress-config
!
hostname asdf
!
boot-start-marker
boot-end-marker
!
card type e1 0 0
logging buffered 32768 debugging

Ik had het quick and dirty opgelost door een horizontal tab (\t) voor de \r te doen, maar ook Cisco vind net als bash een tab erg handig voor command-completion. Vervang ik de \r voor een \n, dan krijg ik in mijn mail tussen elke regel gratis een lege regel, ook niet echt handig..

Google heb ik al geprobeerd ondersteboven te halen, maar het lukt me niet om een werkend antwoord boven water te krijgen, dus daarom hier de vraag!

[MissingDog]

gaat er iets mis met de character-encoding / mime type hier? Het grote UNIX newline != Windows newline verhaal? Lees je je mailbox uit op de console of met een windows-client?

[Sprite_tm]

Als ik hier even een mailtje door de hexeditor haal, kom ik erop uit dat het 0x0A lijkt te gebruiken voor een nieuwe regel, wat gelijk staat aan een printf"\n"; dat zou dus moeten werken. Is het niet zo dat een \n al geimpliceerd word omdat je de printf-opdrachten over meerdere regels verdeeld hebt en zo zeg maar de newlines daarin ook quote? Wat gebeurt er als je het opdeelt in meerdere printf-statements, of gewoon alle \rs weghaalt?

Edit: Ja dus:

jeroen@laptop:~$ cat bla.sh 
printf "bla
bla2\n"
jeroen@laptop:~$ ./bla.sh 
bla
bla2
jeroen@laptop:~$

[ Voor 13% gewijzigd door Sprite_tm op 03-01-2007 14:22 ]

[Whizzer]

@MissingDog:
De mail lees ik via mijn outlook, windows dus. Voor de volledigheid, mijn mailbox staat op een exchange server, dus sendmail op de linux doos forward alle mail middels een smarthost naar onze exchange omgeving.

@Sprite_tm
als ik de \r weghaal aan het einde van regels lijkt er geen verschil te zijn, zowel in de redirect naar een text file als richting de mail. Dus dat blijft allemaal hetzelfde.

Opdelen in meerdere printf statements is een optie die ik graag wil proberen, maar hoe redirect ik meerdere printf statements naar 1 mail zonder tussenkomst van een textfile?

[Sprite_tm]

Whizzer: Uit mijn hoofd:

code:

{
echo yadda
echo bla
echo blaat
} | mailprogje

[Whizzer]

Inderdaad werken die accolades goed, maar helaas blijft de output van het verhaal hetzelfde... Dus tekstfile is goed, email in outlook is zwaar vernaggeld...

Edit: Kleine update, wanneer ik de mail naar bijvoorbeeld een gmail account stuur, lijkt ie wel goed over te komen.... Het lijkt erop dat de mail info lijkt te missen (of juist teveel heeft) waar Outlook niet blij van wordt... Maar wat zou dat weer zijn?

[ Voor 45% gewijzigd door Whizzer op 03-01-2007 15:37 ]

[frim]

Ik denk dat Outlook een iets te agressieve anti-wordwrap doet, waardoor het alles op één regel zet. Je kunt die optie misschien uitzetten in Outlook, of anders een HTML-email versturen met <br />'s erin. In ieder geval lijkt dit me meer een Windows-issue dan een NOS-iets.

[Whizzer]

@frim:
ben het niet helemaal met je eens (maar dus ook niet geheel oneens)... Wellicht dat er iets is met de wordwrap van Outlook, maar de mailtjes die ik dagelijks van de logwatch krijg vanaf dezelfde machine komen wel gewoon netjes binnen. Dus het KAN wel...

Een HTML mail versturen was ook al iets waar ik even aan heb zitten denken, maar ik ben bang dat ik dan alles helemaal overhoop moet gaan halen, waardoor het simpele script nu ineens gecompliceerd gaat worden waardoor dadelijk niemand anders het meer begrijpt (en misschien ikzelf ook niet)

[tomato]

Whizzer schreef op woensdag 03 januari 2007 @ 15:18:
Edit: Kleine update, wanneer ik de mail naar bijvoorbeeld een gmail account stuur, lijkt ie wel goed over te komen.... Het lijkt erop dat de mail info lijkt te missen (of juist teveel heeft) waar Outlook niet blij van wordt... Maar wat zou dat weer zijn?

Vergelijk het mailtje met die van logwatch waarvan je zei dat ze wel goed werden weergegeven.

[MrNGm]

In mijn backupscript staat het volgende:

code:

echo "Laatste full was op `cat lastfull.txt`. 
    
FTP output: `cat upload` 
  
$GREETING"

Dat komt er gewoon goed uit (zoals ik het heb ingevoerd dus). Probeer eens de \r's weg te halen.

[Whizzer]

Zo, gisteren even een dagje niet de mogelijkheid gehad om te testen, maar we gana weer verder. Zojuist de header tussen de logwatch mail en het "script mailtje" vergeleken en daarin zie ik wel iets wat voor mijn gevoel misschien een oorzaak zou kunnen zijn van dit probleem.

In de logwatch header staan de volgende regels wel, welke in mijn scriptje niet staan:

MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"

Nu alleen uit zien te zoeken hoe ik deze opmaak/regels ook in mijn scriptje gepropt krijg... iemand een idee?

[JeroenE]

Hoe stuur je je logfile op? Hoe is dat anders dan de manier waarop je deze output wil sturen? Waarschijnlijk gaat het beter als je de output eerst naar een tijdelijk bestand zet en deze dan opstuurt a la de manier waarop je de logfile laat opsturen.

Een andere oplossing is wellicht de optie "Extra regeleinden verwijderen in berichten zonder opmaak" in je Outlook uit te zetten. Dat is altijd 1 van de eerste dingen die ik uitzet. In de versie die ik nu gebruik: Extra -> Opties, button Email opties en dan het 4e vinkje.