LinuxQuestions.org - [SOLVED] /etc/nanorc empty after last current updates

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - /etc/nanorc empty after last current updates (https://www.linuxquestions.org/questions/slackware-14/etc-nanorc-empty-after-last-current-updates-4175597288/)

/etc/nanorc empty after last current updates

ls -la /etc/nanorc*
-rw-r--r-- 1 root root 0 Jan 10 17:34 /etc/nanorc
-rw-r--r-- 1 root root 8777 Nov 3 15:07 /etc/nanorc.orig

ap/nano-2.7.4-x86_64-2.txz: Rebuilt.
Fixed /etc/nanorc.new. Thanks to SeB.

Weird, as the new nanorc weighs 8777 bytes.

Anyway I attach the new one. You can check it is the new one as it includes

Code:

# set numbercolor cyan

and line numbering is a new feature.

Confirmed.

Code:

test@ws1:~$ tar -tvf /srv/slackware/slackware64-current/slackware64/ap/nano-2.7.4-x86_64-1.txz etc/nanorc.new

-rw-r--r-- root/root        0 2017-01-10 22:34 etc/nanorc.new

Hello,

nano.SlackBuild fails to generate nanorc.new because the source for this file has been renamed from nanorc.sample to sample.nanorc :

Code:

$ ls nano-2.6.0/doc/*nanorc*

nano-2.6.0/doc/nanorc.sample  nano-2.6.0/doc/nanorc.sample.in

...



$ ls nano-2.7.4/doc/*nanorc*

nano-2.7.4/doc/nanorc.5      nano-2.7.4/doc/sample.nanorc

nano-2.7.4/doc/nanorc.5.html  nano-2.7.4/doc/sample.nanorc.in



$ grep nanorc.new nano.SlackBuild

sed 's?^# include?include?g' doc/nanorc.sample > $PKG/etc/nanorc.new 



$ ./nano.SlackBuild 

....

make[2]: Leaving directory `/tmp/nano-2.7.4'

make[1]: Leaving directory `/tmp/nano-2.7.4'

mkdir: created directory ‘/tmp/package-nano/etc’

sed: can't read doc/nanorc.sample: No such file or directory

cp: cannot stat ‘BUGS’: No such file or directory

cp: cannot stat ‘UPGRADE’: No such file or directory

cp: cannot stat ‘doc/nanorc.sample’: No such file or directory

...

--
SeB

These kind of errors could have been caught, if ...

Why isn't "set -e" used in Slackware's scripts?

This is the third time already:

Seamonkey 2.46: missing include files
Subversion 1.7.22 (in 14.0 and probably 14.1 as well): ruby language binding fails to build
And now Nano.

Most SBo scripts actually do a "set -e".

Anyway, it's fixed already in latest current update

Quote:

Originally Posted by MadMaverick9 (Post 5654150)

These kind of errors could have been caught, if ...

Why isn't "set -e" used in Slackware's scripts?

This is the third time already:

Seamonkey 2.46: missing include files
Subversion 1.7.22 (in 14.0 and probably 14.1 as well): ruby language binding fails to build
And now Nano.

Most SBo scripts actually do a "set -e".

Careful, the goal of SBo was to not differ from Slackware's SlackBuilds and then having users question Pat's scripts ;)

Quote:

For that reason, the golden rule was established that all SlackBuild entries at slackbuilds.org would follow the style of the “mother” scripts. Basically, a SBo script should be transferable into the Slackware core distro without feeling out of place. I think it was this rule that made Pat give the nod of approval. Just think of the scenario where the SBo site would become popular using a style of SlackBuild scripts that did not look at all like Slackware’s own. There was a good chance that people would start demanding that Slackware must adopt the scripting style of SBo. This was a big no-no.

SOURCE: http://alien.slackbook.org/blog/ten-...ackbuilds-org/

NOTE: I don't think that a minor change like set -e was what they were thinking of when they were intending to not differ from the "mother" scripts and I said the above jokingly. Overall, it probably wouldn't be a bad idea for Pat to incorporate set -e into future versions of his SlackBuild scripts, but as always, it's his distro, so we'll see what happens.

Quote:

Originally Posted by MadMaverick9 (Post 5654150)

These kind of errors could have been caught, if ...

Why isn't "set -e" used in Slackware's scripts?

This is the third time already:

Seamonkey 2.46: missing include files
Subversion 1.7.22 (in 14.0 and probably 14.1 as well): ruby language binding fails to build
And now Nano.

Most SBo scripts actually do a "set -e".

If it is supposed to be a fatal error, I use || exit 1 after the command. But "set -e" does not work well when an error should be considered "soft" -- for example, I like to try to pack up any documentation file that's ever been seen in the sources, and don't want to have to edit that list when a file disappears. And if it's only gone for one release, editing the list could cause it to be dropped if it returns.

Basically, there are pros and cons to either approach, but I prefer to handle erroring out line by line.