zoeken op een letter

[JosVa]

Als ik in mappen ga zoeken naar namen dan zoekt de tool vergrootglas niet op een (1) letter. Dat is jammer want je kunt in de bestands- en foldernaam heel wat karakters invoeren waarmee Mint v20 wel goed werkt
maar.......
rsync niet mee overweg kan en een failure meldt. En ook Thunderbird dat bestand niet zal accepteren als bijlage.
Na het vervangen of wissen van die illegale tekens werken rsync en Thunderbird dan weer wel. Dat zijn bijvoorbeeld een komma, aanhalingsteken, spatie+punt en nog wat andere in de folder- en bestandsnaam. Gek genoeg heeft Office er ook geen problemen mee om de files met "ongeldige" karakters in de bestandsnaam toch op te slaan.
Stel dat je met de zoekoptie (vergrootglas) naar alleen die karakters kon zoeken dan kun je je schijf diep op die fout en met de hand aanpassen.
Nog afgezien daarvan dat Mint v20 niet bij het opslaan ook wel effetjes dat aan je had kunnen melden inplaats van daar pas later niet mee accoord te gaan.
Iemand een oplossing of moet ik dit melden aan het Mint-team?

[emvedeesje]

Linux gebruikt die speciale tekens in bashfiles.
Daarom gebruik je best volgende tekens niet:
&|@"#'(§^!{})°^"[$*]%'£`,?;:/=+ space
Ik gebruik enkel -_en.

Waarom laat linux dat toe?
Wat zou je zeggen moest je een bestand binnenkrijgen via e-mail waar in de naam speciale tekens staan, bestand afkomstig van ?
Je zou het niet eens kunnen downloaden moest linux dat niet toelaten.

Waak over je bestandsnamen en mapnamen.

groeten van Michael

[JosVa]

Dacht ik toch effetjes dat we op onze computers al naar Mars kunnen vliegen. Moet ik dan toch nog een fiets meenemen?

[Joan]

In veel gevallen kun je met het * of ? teken namen completeren en daarmee met een deel van een naam zoeken.

[emvedeesje]

Ook in je computer die naar Mars wil vliegen, zal je ermee geconfronteerd worden...
Er zijn nu eenmaal basisregels.

[JosVa]

Joan, hartstikke bedankt want * of ? toevoegen is de oplossing die ik wel ken maar niet aan gedacht heb.
Middels *,* als zoekargument krijg ik nu alle folders en bestanden met een komma in de naam heel overzichtelijk op scherm die ik na handmatig via F2 en aanpassen nu wel kan rsync'en.
En emvedeesje bedankt voor de aanvulling van niet werkende tekens in folder- en bestandsnamen.

[JosVa]

In mijn bestanden op zoek naar die niet werkende tekens valt mij op dat er een massa van op de schijf staan. Velen zijn jarenlang via email of internet gesaved en doen hun werk goed maar zijn potentieel een probleem bij verdere verwerking. Lijkt een beetje op toch nog vlug effetjes door oranje rijden. Meestal gaat het goed maar soms...............en wat dan? Had dat van begin af aan niet toegestaan dan kun je achteraf veel problemen voorkomen.
rsync -a -r -v /home/HP/Documenten /media/HP/USB/backup >> /media/HP/USB/output-mint.txt
En als we dan dan toch bezig zijn: Weten jullie wel hoeveel spaties er staan tussen:
Documenten /media
en
/backup >> /media
Wordt ook effetjes en tegenwoordig steeds meer en vooral ongevraagd door de moderne software geregelt die precies weet wat jij wilt en niet doet!

[MenthaSuaveolens]

Ik lees hier dat rsync en Thunderbird niet met speciale tekens overweg zou kunnen. Wel dat verhaal moet je als het volgt nuanceren. Het probleem steekt hem in het feit dat Windows-systemen niet met dergelijke speciale tekens overweg kunnen. Windows kan bv. niet overweg met het eenvoudige bestand Log18:30.txt. Om te vermijden dat dergelijke bestanden met email verstuurd zouden kunnen worden, werd in de beginperiode van het internet enkele regels afgesproken: https://datatracker.ietf.org/doc/html/rfc5322.
rsync kan wel overweg met geldige Linux-bestandsnaam als je rsync gebruikt als bestandsoverdracht tussen linux-systemen (bv. schijven met ext4-extensie en dergelijke meer). Als je rsync gaat gebruiken voor dataoverdracht naar een schijf die NTFS geformateerd is, dan zal dat normaliter niet lukken omdat Windows-compatibiliteit verwacht wordt.
Je kan eventueel toch Linux-compatibiliteit opleggen door de schijf met de optie utf8 te koppelen bv.

Code: Selecteer alles

# Creating a mount-point
mkdir Test
# Creating a dummy file to be transferred to the NTFS-partition
touch file:test.txt
# Mounting the external drive on the mount-point
sudo mount -t ntfs -o utf8 /dev/sdc1 ./Test
# Copying file
cp file\:test.txt Test

Ik merk bv. dat je al het bestand Log18:30.txt naar een NTFS- of FAT-geformateerde schijf wil kopiëren, dat Nemo dan automatisch het bestand naar een Windows-compatibele versie converteert.

[JosVa]

Bedankt MenthaSuaveolens want Inderdaad is de overdracht van namen beperkt doordat de schijven nog steeds Windows geformateerd zijn want ik draai sinds jaren Linux en Windows multiboot op onze PC's. Windows als XP en W7 die geen toegang hebben tot het internet (voor de veiligheid) maar wel sommige oudere apparatuur en programma's nog perfect ondersteunen.
Tot en met W7 (Vista even overgeslagen) was Windows een redelijk vriendelijk systeem maar met W10 kreeg ik daar langzaam genoeg van en vond in Linux een goed alternatief. Moest wel het een en ander afleren en bijleren. Ik merk helaas steeds meer dat de programmeurs ervan uitgaan dat jij toch al doet wat zij bedenken en zij daar helaas vaak slecht hulp in verlenen. Helaas waarschuwt Linux je ook nog eens bijna niet voor. Nog afgezien daarvan dat alles stap voor stap steeds complexer wordt. En niet alleen op de PC want de papieren QR-code voor coronavaccinatie is slecht leesbaar door veel moderne apparatuur

[MenthaSuaveolens]

Ik was benieuwd wat er allemaal in die QR-code van het vaccinatie-bewijs stond. Je kan op je pc eveneens een qr-code van papier scannen. Je kunt daarvoor QtQr gebruiken en de optie decodeer van webcam gebruiken. Na een tijdje verschijnt dan een dialoog met de output van je camera op. Met enige handigheid (weliswaar) en als je dicht genoeg bij de camera-lens raakt, dan kan QtQr de QR-code lezen. Het is wel gemakkelijker je bewijs te downloaden, de QR-code uit de pdf op te slaan en vervolgens die afbeelding met QtQr te analyzeren.

Leuk om horen dat je een oplossing voor je probleem hebt kunnen vinden. Linux kent nauwelijks belemmeringen op de naam van een bestand. Je kan daar eigenlijk best wel gekke dingen mee doen, als je bv. niet-displaybare karakters in je bestandsnaam gaat plaatsen. Het is jammer dat Windows nog altijd geen onderscheid weet te maken tussen lower- en upper-case in de bestandsnamen. Op een linux-systeem kan je perfect de bestandsnamen zoals bv t.txt en T.txt naast elkaar hebben.

[JosVa]

Helaas ben ik weer wat aan het testen geslagen en snap toch enkele zaken niet helemaal.
Wat kan wel? Onder Mint met als naam !@#$%^&*()_+ een bestand opslaan is geen probleem op Linux-format, NTFS, FAT of direct kopieeren van de ene naar de andere format schijf.
Wat kan niet? Onder WIndows dat bestand lezen op een Linux-format. Wel lezen op NTFS en FAT maar niet kopieeren van NTFS naar NTFS.
Wat kan wel? Onder WIndows kopieeren van FAT naar NTFS.
Maar zoals gebruikelijk zal ik wel weer wat verkeerd doen want helemaal begrijpen doe ik het nog steeds niet.

Wat ik steeds meer merk is dat alles onder water steeds ingewikkelder wordt. Waar ik nog begonnen ben met een 360Mb floppy en de computer alles deed wat ik nodig had, zijn tegenwoordig heel veel gigabytes nodig en dan alleen nog maar om op te starten. Dat de programmeurs dan wel eens een zijstraatje over het hoofd zien..........tja dan krijg je toch elke maand een update/upgrade. En een puzzel met 1000 stukjes is toch ook veel onoverzichtelijker dan dezelfde van 100. En waar ik mijn eerste auto nog aan de rand van de snelweg kon bijstellen zodat ie wel 140 km/h haalde, zit ik nu dom te kijken als er een lampje gaat branden.

[MenthaSuaveolens]

Hm ... Ik ken dat gevoel. Ik begin beginnen software ontwikkelen op een systeem met CP/M en 2 floppy-drives van 8". Wel dergelijke floppy had een capaciteit van 360 Kb (en niet Mb zoals je vermeldt --- eigenlijk 1000 maal kleiner). Mijn eerste vaste schijf had een capaciteit van 5 Mb (waarvan ik geloofde die nooit vol te zullen kunnen schrijven). In die tijd waren we gedwongen zeer efficiënt code te ontwikkelen. In de loop der tijd verdween die noodzaak door de komst van snellere hardware. Efficiënt code ontwikkelen kost tijd (en dus geld). Het is minder noodzakelijk geworden en dus gebeurt het niet meer.

Let op. Er bestaan verschillende FAT-versies (bv. FAT16, FAT32, ...).

[aartje]

Wat ik steeds meer merk is dat alles onder water steeds ingewikkelder wordt. Waar ik nog begonnen ben met een 360Mb floppy en de computer alles deed wat ik nodig had, zijn tegenwoordig heel veel gigabytes nodig en dan alleen nog maar om op te starten.

Dat zal wel 360 KByte moeten zijn, dacht ik. Mijn eerste Unix-systeem (Unix6) had 128 KByte geheugen (kernel van 20 KByte), helaas nog geen
netwerkmogelijkheden, daarvoor was een parallel-OS nodig, dat switchte met Unix (ok, ook zo'n 20 KByte...)

Op de hoofdsystemen zat je op een gegeven moment te werken met een geheugen van 4 MByte, een (removablepack)HD van 80Mbyte
en dat met een man of 15 tegelijk.

Kom daar maar eens om tegenwoordig

[Joan]

Het wordt niet ingewikkelder. Het zijn nog steeds 0 (nullen) en 1 (enen).
Wat wel veranderd zijn de wensen van mensen die allerlei kleuren willen en plaatjes en internet en cload en navigatie en google en facebook. Daar zijn meer 0en en 1en voor nodig en een uitgebreidere commando set.

Ondanks dat is het geheel exponentieel sneller geworden, wat de aanpassing van de 1 en 0 veroorzaakte en allemaal een andere volgorde hebben gekregen. Het is daarbij wonderbaarlijk dat nog steeds veel de zelfde dos commando's kunnen worden gebruikt.

[MenthaSuaveolens]

Dag Joan, "dos commando's" ? Je bedoelt wellicht de oude Unix-commando's van begin de jaren 70. Dergelijke commando's kunnen zelfs nog op MacOS gebruikt worden. Jammer dat Bill Gates en Co voor een eigen systeem gegaan zijn met een beperkte toegelaten tekenset voor bestandsnamen. Steve Jobs en Co hadden nog het inzicht een UNIX-fork te gebruiken. Het DOS-systeem van Microsoft had dan in de beginfase het voordeel weinig resources te vragen. Jammer dat de open-source-gemeenschap er begin de jaren 80 niet in slaagde een UNIX voor de pc uit te brengen. Wie zich wil verdiepen in de geschiedenis van de open-source-gemeenschap moet beslist eens het lezenswaardige boekje "For fun and profit" van Christopher Tozzi lezen. Je leest er zelfs hoe in de jaren 70 de studenten een Unix-mainframe "hackten".