Re: always_bcc / mail archive
On 03/02/2014 12:07 AM, Paul van der Vlis wrote: Hoi, Hmm, er schijnen toch juridische uitspraken te zijn geweest die wat anders beweren. Nu kan ik me ook best voorstellen dat je prive zaken mailt via een zakelijk account, maar dat vind ik niet slim. Of het slim is, is een ander verhaal... bij sommige privé dingen wil je niet met je werkgever geassocieerd worden, en sommige privé dingen wil je zo privé houden dat of de werkgever zich aan de regels houdt of niet een beetje dunne bescherming is. Ook roddelen over het werk kan je beter niet via je werk account doen... ;-) Er wordt niet gezegd dat je de mailbox met always_bcc ook gaat lezen zonder goede noodzaak. Ik neem toch aan dat je als bedrijf toch wel een backup mag hebben o.i.d. Backup magen mag natuurlijk. Bewaren of inzien zonder goede reden niet. Zelf denk ik dat zakelijke mail van het bedrijf is. Als jij opeens ziek wordt, moet iemand anders kunnen zien wat jij beloofd hebt namens het bedrijf. Als jij wilt mailen met privacy, dan kun je dat via een prive mail account doen vind ik. Als je juridisch kijkt, draait het hier om welke verwachting van privacy je als werknemer mag hebben. Daarbij speelt mee: - beleid, reglementen en de aankondiging daarvan - de verwachting dat de werkgever doet wat noodzakelijk is om de continuïteit van de bedrijfsprocessen te waarborgen - de verwachting dat de werkgever respect heeft voor de persoonlijke levenssfeer van de werknemer Dit levert natuurlijk veel grijze gebieden op, maar het resulteert in twee hoofdregels: - als de werkgever er noodzaak toe heeft, mag er in de mail gekeken worden - als mail evident privé is, dan moet de werkgever dat respecteren groet, Winfried -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5312e760.2010...@tilanus.com
regelparen verwijderen
Hoi, Een programma verwerkt een lijst. Doet dat goed, de output is minder. output Setup info foo Setup info bar Processing data 1 Processing failed Processing data 2 Processing failed Processing data 3 Processing failed Processing data 4 Processing failed Processing data 5 Processing failed Processing data 6 Processing failed knip/ Processing data n Processing failed Processing data n+1 Processing failed Processing data n+2 Processing failed Processing data n+3 Processing failed Processing data n+4 Result: asdfadf Result: asdasferqwe Result: askjkqerqr Processing data n+5 Processing failed Processing data n+6 Processing failed Processing data n+7 Processing failed Processing data n+8 Processing failed knip/ Processing data n+m Processing failed Processing data n+m+1 Processing failed Processing data n+m+2 Processing failed Final statistics /output Wat ik zou willen hebben, is output Setup info foo Setup info bar Processing data n+4 Result: asdfadf Result: asdasferqwe Result: askjkqerqr Final statistics /output Dus dat kopregels met Processing data recordnummer niet getoond worden als de processing is mislukt. De regels met Processing failed zijn ook niet nodig. Met sed en/of awk krijg ik het niet voormekaar. Wat zien jullie aan mogelijkheden? Groeten Geert Stappers -- Leven en laten leven -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140302115040.gx1...@gpm.stappers.nl
Re: always_bcc / mail archive
Interessante discussie. Kijk, privemails horen in feite niet thuis in een werkmailbox, is ons idee. Daarom blokkeren we (bv) gmail, yahoo, hotmail etc helemaal niet. Mensen mogen uiteraard privemails versturen, maar we gaan er vanuit dat ze dat vooral zullen doen via hun eigen webmail adres. (hotmail, gmail, noem ze maar op) Het grootste deel van de mails in onze institutionele mailboxen zullen dus werkmails zijn, werk gerelateerd, en derhalve relevant voor de continuiteit van het instituut. Sommige mensen bewaren zaken 'eeuwig' in hun mailbox, anderen gooien zaken snel weg. Om dingen te kunnen nazoeken, of ook (juridisch) te weten wat er nu EXACT besproken/gezegd is, vind ik dat je zo'n archief mag/moet hebben. Uiteraard ga je daar in de praktijk weinig gebruik van maken. Maar ook werkt het als een simpel backup/restore mechanisme: Een hele mailbox terugzetten van een backup is heel iets anders dan een enkel mailtje zoeken, en aanklikken: restore to mailbox en hij wordt opnieuw via smtp bezorgd. Ik zal deze hele discussie trouwens komende week wel eens even laten lezen aan de baas, want er zijn best veel zinnige dingen gezegd. Dank. MJ -- To UNSUBSCRIBE, email to debian-user-dutch-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53133908.9010...@merit.unu.edu
Re: regelparen verwijderen
Op 2014-03-02 om 16:22 schreef Geert Stappers:
Op 2014-03-02 om 13:17 schreef Wouter Verhelst:
Op zondag 2 maart 2014 12:50:40 schreef Geert Stappers:
Dus dat kopregels met Processing data recordnummer niet getoond
worden als de processing is mislukt. De regels met Processing failed
zijn ook niet nodig.
Met sed en/of awk krijg ik het niet voormekaar.
Met awk zou dat toch moeten lukken, en is redelijk simpel:
knip/
Wat mist nog: Setup info en Final statistics. Dat lijkt een mooie
oefening
voor de lezer ;-)
Gelukt.
Nog bedankt voor de tip (en de uitdaging)
#!/usr/bin/awk -f
BEGIN {
state = loud;
}
State machine krijgt zijn begin waarde
/Processing data/{
header = $0 ;
state = silent ;
}
De header wordt bewaard
!/Processing failed/ state == silent !/Processing data/ {
Niet de foutmelding, we zwijgen nog en niet een nieuwe header.
print header ;
state = goloud ;
}
Eenmalig de bewaarde header afdrukken
!/Processing failed/ state == goloud !/Processing data/ {
state = loud ;
Deel twee van het eenmalig afdrukken.
}
!/Processing failed/ state == loud {
print $0 ;
Andere regels dan failed afdrukken.
}
# l l
Toelichting in de follow up.
In de bijlage het awk script en test materiaal.
Doe er je voordeel mee.
Groeten
Geert Stappers
--
Leven en laten leven
#!/usr/bin/awk -f
BEGIN {
state = loud;
}
/Processing data/{
header = $0 ;
state = silent ;
}
!/Processing failed/ state == silent !/Processing data/ {
print header ;
state = goloud ;
}
!/Processing failed/ state == goloud !/Processing data/ {
state = loud ;
}
!/Processing failed/ state == loud {
print $0 ;
}
# l l
Setup info foo
Setup info bar
Processing data 4
Processing failed
Processing data 5
Result: asdfadfader
Result: asdfsdeweradf
Processing data 6
Processing failed
Processing data n+4
Result: asdfadf
Result: asdasferqwe
Result: askjkqerqr
Processing data n+5
Processing failed
Final statistics
Re: always_bcc / mail archive
On 02-03-14 14:58, mourik jan heupink wrote: Kijk, privemails horen in feite niet thuis in een werkmailbox, is ons idee. Ik neem aan dat dit helder gecommuniceerd is naar de werknemers, en dat dit niet bij jullie idee blijft. Daarom blokkeren we (bv) gmail, yahoo, hotmail etc helemaal niet. Mensen mogen uiteraard privemails versturen, maar we gaan er vanuit dat ze dat vooral zullen doen via hun eigen webmail adres. (hotmail, gmail, noem ze maar op) Gecommuniceerd dus? Het grootste deel van de mails in onze institutionele mailboxen zullen dus werkmails zijn, werk gerelateerd, en derhalve relevant voor de continuiteit van het instituut. Sommige mensen bewaren zaken 'eeuwig' in hun mailbox, anderen gooien zaken snel weg. Om dingen te kunnen nazoeken, of ook (juridisch) te weten wat er nu EXACT besproken/gezegd is, vind ik dat je zo'n archief mag/moet hebben. Ook het feit dat je de backup maakt is iets dat je moet communiceren geloof ik. Overigens heb ik in deze thread een paar keer vind ik gelezen. Dat is in privacy discussies geheel niet relevant natuurlijk. Het gaat er op waar mensen recht op hebben (de plichten vind ik niet zo interessant, want die komen meestal wel goed). Paul signature.asc Description: OpenPGP digital signature
