Bash maakt files kaduuk?

[Mar2zz]

Beetje vreemd dit.
Ik heb twee files die ik uit mijn dropbox haal. Van te voren zijn de files getest en ze werken prima als de variablen gevuld zijn. Het gaat om deze twee:
http://dl.dropbox.com/u/18712538/Periscope/scanPath.sh
http://dl.dropbox.com/u/18712538/Periscope/SabtoPeriscope.sh

Met een periscopeinstallscript laat ik er wat wijzigingen in doen met sed en ik chmod +x ze ermee.

Daarna zijn de files stuk (ik weet niet of het nou het wijzigen betreft of niet, maar als ik de files wil executen met ./scanPath.sh dan zegt de terminal Bestand of map bestaat niet, terwijl ie duidelijk bestaat:

mars@Lynxtop:~/.periscope$ ./scanPath.sh
: Bestand of map bestaat niet
mars@Lynxtop:~/.periscope$ dir
downloadSub.py	    periscope.py       SabtoPertoSick.py
__init__.py	    plugins	       scanPath.sh
movies-scanPath.sh  SabtoPeriscope.sh  version.py

Het gekke is, als ik alle tekst uit scanPath.sh in een nieuwe file paste, die executable maak, dat die gewoon naar behoren werkt. Ergens gaat er dus iets falikant mis? Ik heb werkelijk geen idee....

[swbr]

D'r zit waarschijnlijk een character achter die filenaam dat je niet kunt zien...

[blaataaps]

Wat gebeurt er als je bash -x in het script zet? Wat is de kleinste opzet dat het nog "kapot" gaat? Wat zegt diff over de verschillende bestanden?

[Mar2zz]

Ik kan 'm niet diffen, ik krijg dezelfde melding. -x wil dus ook niet, want hij gaat niets doen. Ik heb de 'gewraakte' file hier neergezet: http://dl.dropbox.com/u/18712538/scanPath.sh

[DataGhost]

Ik denk dat de regeleindes een beetje gesloopt zijn (lees: windows-stijl). \r is namelijk een carriage return (ga naar begin van de regel) en windows gebruikt \r\n. Op de eerste regel staat dus effectief "#!/bin/bash\r" en "/bin/bash\r" kan niet gevonden worden. Er staat dan waarschijnlijk ook "/bin/bash\r: Bestand of map bestaat niet"

[blaataaps]

Heb je er met windows-tools aangezeten? Waarom kun je hem niet diffen?

[Mar2zz]

Ik heb geen eens windows in huis... in de eerste regel staat #!/usr/bin/env bash

Ik heb andere scripts op dezelfde manier bewerkt met een installscript en dat werkt wel gewoon goed.
Als ik de inhoud overzet ook:

mars@Lynxtop:~/test$ ./geplakteinhoud.sh
--------------------------
do feb 3 21:40:54 CET 2011
: Starting subtitle search
find: ‘home/mars/Films’: Bestand of map bestaat niet
do feb 3 21:40:54 CET 2011
: Subtitle search ended
--------------------------
mars@Lynxtop:~/test$ ./scanPath.sh
: Bestand of map bestaat niet
mars@Lynxtop:~/test$ 

Als ik diff (het kan dus toch blijkbaar srry...) krijg ik de volgende melding:

code:

mars@Lynxtop:~/test$ diff geplakteinhoud.sh scanPath.sh
1,31c1,31
< #!/usr/bin/env bash
blahdieblah

[ Voor 54% gewijzigd door Mar2zz op 03-02-2011 22:34 ]

[Mar2zz]

Ik denk dat het ging om een corrupte file ofzo. ik heb het nu gefixed door andere files te maken met dezelfde inhoud en die mijn dropbox-files te laten overschrijven voor de 2e keer.

toch blijft het vaag... ik hoop niet dat dropbox die corruptie veroorzaakt, ben er net zo aan verknocht...

En ik maar tvshows downloaden om te testen en te testen, terwijl het eerder prima werkte... het is nu weer als vanouds gelukkig...

[ Voor 96% gewijzigd door Mar2zz op 03-02-2011 22:39 ]

[deadinspace]

DataGhost schreef op donderdag 03 februari 2011 @ 21:31:
Ik denk dat de regeleindes een beetje gesloopt zijn (lees: windows-stijl). \r is namelijk een carriage return (ga naar begin van de regel) en windows gebruikt \r\n. Op de eerste regel staat dus effectief "#!/bin/bash\r" en "/bin/bash\r" kan niet gevonden worden. Er staat dan waarschijnlijk ook "/bin/bash\r: Bestand of map bestaat niet"

Wat DataGhost zegt. dos2unix over die files heen halen had het gefixt in dat geval.

[mace]

idd klassiek gevalletje line-terminators.

[Mar2zz]

Jullie hebben gelijk, ik heb er even op gewikipediaat, voor mij onbekend fenomeen...
testje wijst uit dat scanPath.sh (de foute) CRLF (DOS) gebruikt en de goeie (nadat ik geplakt heb in een andere file voor reparatie) LF (UNIX).

mars@Lynxtop:~/test$ egrep -l $'\r\n' *.*
scanPath.sh
mars@Lynxtop:~/test$ egrep -L $'\r\n' *.*
geplakteinhoud.sh

Maar hoe voorkom ik dat dat gebeurt?

[blaataaps]

Uitvinden welke stap het kapotmaakt,en die stap aanpassen?
Op het einde altijd nog een keer dos2unix draaien?

[Mar2zz]

Ik snap niet hoe het kan gebeuren, ik werk alleen op linuxmachines, en dan met gedit en nano. maar dat dos2unix is wel een idee om te doen voordat ik iets naar dropbox doe of github push.

[Borromini]

Het probleem kan toch ook bij Dropbox liggen? Ik heb bv. ook al van bepaalde pastebins gehoord dat ze je CRLF line endings in je data dumpen.

Je kan trouwens altijd netjes checken met file of een bestand CRLF endings heeft of niet, al kan het wel zijn dat je daarvoor de extensie/shebang moet verwijderen eerst - anders pikt ie het op als een bash script, en ik denk dat het dat dan negeert (niet zeker).

[mace]

Mar2zz schreef op vrijdag 04 februari 2011 @ 07:13:
Jullie hebben gelijk, ik heb er even op gewikipediaat, voor mij onbekend fenomeen...
testje wijst uit dat scanPath.sh (de foute) CRLF (DOS) gebruikt en de goeie (nadat ik geplakt heb in een andere file voor reparatie) LF (UNIX).

mars@Lynxtop:~/test$ egrep -l $'\r\n' *.*
scanPath.sh
mars@Lynxtop:~/test$ egrep -L $'\r\n' *.*
geplakteinhoud.sh

Maar hoe voorkom ik dat dat gebeurt?

Dit is makkelijker te testen met het 'file' commando.

[Mar2zz]

Het is het makkelijkst te testen met de code die je ff kan knippen/plakken had 'm er net bij staan bij wikipedia... de file commands ervoor stonden net iets lager...

Heb er nog iets over gevonden. Heb mijn git maar ff geforced naar LF endings:
van Github

Dealing with line endings

Line endings… the scourge of every Windows-based developer that tries to mingle with linux- or mac-based developers. Though most modern text editors can handle both newline types without issue, git is not as graceful.

For more info on the issue see Wikipedia.
Mac and Linux users, you don’t get to sit this one out

Although you might think you’re immune to CRLF-ended files on mac and linux, you are not. It is possible to download files from an external source that use CRLF, and thus commit them into your repo. To be safe, you should set your config to convert line endings on commit so they are always LF in the repo:

$ git config --global core.autocrlf input

[ Voor 71% gewijzigd door Mar2zz op 04-02-2011 16:01 ]